allow uuid being created and managed by kubernetes #73
Conversation
We utilize Helm's `lookup` command to store a generated `uuid` in an "internal" secret in Kubernetes. This allows generating the `uuid`, making it persistent, and notifying the user (in `NOTES.txt`) that this auto-generation happened. We also tell the user how to disable the message by making that value persistent in values. close apache#39
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: {{ template "couchdb.fullname" . }}-internal | ||
| labels: | ||
| app: {{ template "couchdb.fullname" . }} | ||
| chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" | ||
| release: "{{ .Release.Name }}" | ||
| heritage: "{{ .Release.Service }}" | ||
| type: Opaque | ||
| data: | ||
| uuid: {{- include "couchdb.uuid" . }} |
There was a problem hiding this comment.
I'm not convinced about adding another secret resource here. The secret values erlangCookie, cookieAuthSecret are similarly internal only. It seems like a good clarification to split internal/external secrets but that could be a separate PR (and likely major version bump).
There was a problem hiding this comment.
I'm happy to tie this into the existing secret if you want 😄 I was mostly isolating because it is being used a bit differently than the other secret - in a somewhat "idempotent" type of fashion where we look up values from it / etc.
It's also a bit tricky whether you use data: or stringData: because it affects whether we need to base64 encode the value... although - this actually looks like it might be a bug. I'll do some more sanity checking. It may need to be another secret if we want to pass stringData as the verbatim value. Or we can use the existing secret and b64enc the value first.
Your call on preference here!
There was a problem hiding this comment.
@willholley Thoughts on the right approach here? Would you prefer me to tie this into the existing secret?
What this PR does / why we need it:
We utilize Helm's
lookupcommand to store a generateduuidin an "internal" secret in Kubernetes. This allows generating theuuid, making it persistent, and notifying the user (inNOTES.txt) that this auto-generation happened. We also tell the user how to disable the message by making that value persistent in values.Which issue this PR fixes
Special notes for your reviewer:
Happy to discuss this approach, messaging, etc. We have found similar patterns to strike a decent balance when secrets / inputs must exist outside of the application.
Open question: should we allow
dangerRegenerateAutomatedValues?(will walk through checklist once validated as a decent approach)
TODO: update docs accordingly / remove the
uuidgenerationChecklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.