Open michaelgeorgeattard opened 6 years ago
@michaelgeorgeattard Hey! Thanks for raising this.
helmfile as of today doesn't store any external state itself, which is necessary to support this kind of use-case.
You may find it ugly but a possible work-around would be to use {{ exec ... }}
template function that persists and fetches the randomly generated name. More concretely, you may write a single bash script that fetches an external datastore for existence of the generated name, generating and persisting it when it didn't exist yet. So that you can call it within your helmfile templates like {{ exec "./the/bash/script" (list "arg1", "arg2") }}
.
@mumoshu Thanks for the detailed response.
I think the cleanest solution today is to modify the dynamic resource name to be static.
same problem here with these kind of secrets, created as hook in order to be persisted:
kind: Secret
apiVersion: v1
metadata:
name: test-secret
annotations:
helm.sh/hook: pre-install
helm.sh/resource-policy: keep
helm.sh/hook-delete-policy: ''
data:
username: {{ .Values.username | b64enc }}
password: {{ randAlphaNum 32 | b64enc }}
@carlosmkb Hey! To be clear, It's the fundamental issue in helm/your chart. Helmfile can't help fixing it. The best bet is you change your secret to accept something like .Values.password
like password: {{ .Values.password }}
and you pre-generate the pass.
@mumoshu using the {{ exec ... }}
approach to generate the value in values.yaml.gotmpl it triggers another revision anyway,
@carlosmkb Nope. This part of my comment is the key
generating and persisting it when it didn't exist yet
Given a chart with a resource template as follows:
This creates a unique name every time
helmfile diff
is run, creating a new release revision withhelmfile apply
.What is the recommended way to work around this issue?