niklas/terdut-operator
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

DESIGN.md §4.1/§6: drop namespace from credentialsSecretRef, add key
CI / test (push) Has been cancelled
Details

Browse Source 
It's always the operator's own namespace by construction now (§6), never
anything else, so there was nothing for the field to vary -- key varies
instead (fixed 'token' when self-generated, whatever a human chose when
adopted from spec.credentialsSecretRef).
This commit is contained in:
Niklas Ye
2026-09-30 22:21:28 +02:00
parent 7f439605c4
commit 5f93a530fa
1 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DESIGN.md
+6 -6
View File
@@ -192,7 +192,7 @@ status:
conditions: [...] # Ready, DatabaseReady, Bootstrapped conditions: [...] # Ready, DatabaseReady, Bootstrapped
observedGeneration: 3 observedGeneration: 3
serviceName: terdut serviceName: terdut
credentialsSecretRef: {name: terdut.platform-oncall-instance-credentials, namespace: terdut-operator-system} # see §6; lives in the OPERATOR's namespace, not this TerdutServer's credentialsSecretRef: {name: terdut.platform-oncall-instance-credentials, key: token} # see §6; lives in the OPERATOR's namespace (always, implicitly -- not stored here), not this TerdutServer's. No `namespace` field: unlike an earlier draft, it's never anything other than the operator's own, so there's nothing to record. `key` replaces it, since that *does* vary -- fixed ("token") when the controller generated this Secret itself, whatever the human chose when it was adopted from spec.credentialsSecretRef instead.
``` ```
Field-for-field this is the chart's `values.yaml` reshaped as a spec — the Field-for-field this is the chart's `values.yaml` reshaped as a spec — the
@@ -493,11 +493,11 @@ when nothing ever crosses into a tenant namespace in the first place.
2. On the self-registration path only (point 1's bring-your-own path 2. On the self-registration path only (point 1's bring-your-own path
generates nothing — it adopts the human-provided Secret directly): the generates nothing — it adopts the human-provided Secret directly): the
resulting instance-scoped key is written to a generated Secret in the resulting instance-scoped key is written to a generated Secret in the
**operator's own namespace** (e.g. `<serverRef.namespace>.<serverRef.name>-instance-credentials`), **operator's own namespace** (e.g. `<serverRef.namespace>.<serverRef.name>-instance-credentials`,
referenced back from `TerdutServer.status.credentialsSecretRef: {name, under a fixed data key, `token`), referenced back from
namespace}` (§4.1) — `namespace` is part of the reference now, since it's `TerdutServer.status.credentialsSecretRef: {name, key}` (§4.1). No
no longer the same namespace as the `TerdutServer` itself. No `OwnerReference` (those can't cross namespaces, and this Secret doesn't
`OwnerReference` (those can't cross namespaces); the `TerdutServer`'s share a namespace with the `TerdutServer` that caused it); the `TerdutServer`'s
finalizer deletes this Secret directly as part of its own teardown, finalizer deletes this Secret directly as part of its own teardown,
the same way it already has to clean up the server-side resources it the same way it already has to clean up the server-side resources it
created (§5's general finalizer rule extends naturally to this Secret). created (§5's general finalizer rule extends naturally to this Secret).