3 messages
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
Will Da Silvaover 1 year ago
I've got a Helmfile with 3 environments (default, staging, and prod). When I run it with the default environment, everything works fine. When I try to deploy into staging with
helmfile apply --environment staging or helmfile sync --environment staging it seems like Helmfile ignores the needs sections. This results in errors because it tries to install charts before required CRDs are defined. Within my environment config I set kubeContext appropriately for each environment. I've tried defining needs with explicit kube context set (i.e. <kube context>/<namespace>/<release name>, and without the explicit kube context part. I've tried setting kubeContext for each release too, in addition to having it defined at the environment level. Does anyone know why Helmfile is failing to install the releases in the order required by needs?Will Da Silvaover 1 year ago
Unrelated to the above, is it possible to set environment variables in
helmfile.yaml that can be used by vals references (i.e. ref+protocol://), or by templates using {{ env ... }} / {{ requireEnv ... }}? In my case I have many vals refs to the Pulumi API, and I can either repeat the same 3 query parameters for each ref, or set env vars for them. I'd like to keep this self-contained by not requiring env vars be set when running helmfile commands, but I also don't want to repeat the query parameters for each ref. Ideally I could do something like this:environments:
default:
env:
PULUMI_ORGANIZATION: my-pulumi-org
Michael Levover 1 year ago
Hello guys!
I might be missing something, can anyone help? 🙂
How can I elegantly avoid a failure for helm chart dependancy installation that fails for it's CRD ownership?
For example if I need Prometheus or ExternalSecrets CRDs I add them as a dependancy in the Chart.yaml but their owners are different so I fail.
What am I missing? 🙂
Something like this:
I might be missing something, can anyone help? 🙂
How can I elegantly avoid a failure for helm chart dependancy installation that fails for it's CRD ownership?
For example if I need Prometheus or ExternalSecrets CRDs I add them as a dependancy in the Chart.yaml but their owners are different so I fail.
What am I missing? 🙂
Something like this:
Unable to continue with install: CustomResourceDefinition "<http://acraccesstokens.generators.external-secrets.io|acraccesstokens.generators.external-secrets.io>" in namespace "*****" exists and cannot be imported into the current release: invalid ownership metadata;