#helmfile (2024-10)

https://github.com/helmfile/helmfile

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

Will Da Silva avatar
Will Da Silva

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 Silva avatar
Will Da Silva

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
yxxhero avatar
yxxhero

could you post the issue into helmfile github repo?

yxxhero avatar
yxxhero

@Will Da Silva

Will Da Silva avatar
Will Da Silva

Sure

Will Da Silva avatar
Will Da Silva

It seems like issues in that repository are specifically for bug reports, so I opened a discussion instead per the instructions in the repository

yxxhero avatar
yxxhero

ok

2024-10-16

2024-10-21

Michael Lev avatar
Michael Lev

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;
    keyboard_arrow_up