#helmfile (2024-10)
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
2024-10-15
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
?
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
could you post the issue into helmfile github repo?
@Will Da Silva
Sure
It seems like issues in that repository are specifically for bug reports, so I opened a discussion instead per the instructions in the repository
ok
2024-10-16
2024-10-21
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:
Unable to continue with install: CustomResourceDefinition "acraccesstokens.generators.external-secrets.io" in namespace "*****" exists and cannot be imported into the current release: invalid ownership metadata;