@Prasanna has joined the channel

@JS has joined the channel

@Salman Shaik has joined the channel

@Deep has joined the channel

https://helmfile.readthedocs.io/en/latest/advanced-features/#deploy-kustomizations-with-helmfile

looking at the docs for deploying kustomization, I didnt quite get what i'm actually creating in helmfile.

what i'm trying to do is effectively set the below but in a declarative fashion

kustomize edit add configmap some-name --from-files=somedir/*.conf

Been thinking about this for a bit but am looking for a sanity check / other ideas. I use vals lookups (i.e. ref syntax) with the s3 terraform state backend. I'm going to refactor terraform and clean up the s3 state paths which are pretty gnarly at present, but the vals backend doesn't support multiple s3 object keys or fallback behavior. Similarly if a vals lookup fails it causes templating to fail instead of rendering to null or an empty string (probably a desirable behavior). I'd like to avoid littering my templates values files with lots of conditionals to inform one of two vals lookups (old path and new path). Is there any helmfile and/or vals feature I'm missing that would help me with transition while I'm refactoring terraform state object paths?

Hi.
I tried to add a strategicMergePatches to a release that uses a Helm chart containing the Helm lookup function.
It seems once kustomize comes into play, the lookup function no longer executes.

Has anyone found a way to destroy/terminate namespaces created by the Terraform resource kubernetes_namespace when they get stuck in the Terminating state?
Right now, the only thing that seems to work is manually clearing the finalizers, like this:
kubectl get ns "$ns" -o json | jq 'del(.spec.finalizers)' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -

Just wondering if anyone's found a cleaner or automated way to handle this by terraform ?

Hello All, I am new to helmfile and I realised that it's really a great tool. But I am facing a problem: I am unable to connect to private git repository using the private access token. I suspect I am using wrong format for the repository url. Can someone please advise how can I do that? Preferably with some code example.

Hey all!

I’m trying to setup a gitops solution based on helm.
All of my yamls are in a monorepo, and I'm not building any charts manually using helm dependency build or any other helm command.

In my solution I will need nested dependencies to be resolved automatically, as I want several layers of values (with overrides for each layer) For example:
/clusters/01/Chart.yaml will have a dependency of /environments/prod
/environments/prod/Chart.yaml will have a dependency of /region/US
/region/US/Chart.yaml will depend on an "umbrella" chart, that this umbrella chart will deploy all apps, while overriding the values according to the precedence of the dependencies.

Using helm in Flux/ArgoCD, I was not able to do that as helm doesn't support recursive dependency building, so only the first 2 charts were deployed.
I tried using basic helmfile examples, but the same limitation still in place.

I wonder if I can somehow leverage helmfile to dynamically resolve all nested dependencies of an helm chart without having to commit all charts' tgz files?

Can I have references like this pseudo code in my environment file?

temporal:
  address: temporal.svc.addr
  api_key: 1234

my_server:
   temporal_addr: $temporal.address

not sure how to handle the sops thingy now :W

thanks

I told claude to implement using this. i hope itll work, lol
https://christianhuth.de/deploying-helm-charts-using-argocd-and-helmfile/

when you push to master, your workflow builds and pushes a docker image to ghcr and updates your helmfile config with the new image tag. that’s the "ci" part done. now for "cd" this is where something like argo cd fits in. argo cd is a gitops based continuous deployment tool that keeps your cluster in sync with your git repo. you would typically store your helmfile in a separate gitops repo or a deployment folder in your mono repo. argo cd watches that repo (or subfolder) for changes. so, when your ci workflow updates the helmfile with the new image tag and pushes that change, argo cd detects it and automatically applies the update to your cluster. in short, argo cd integrates by continuously monitoring your git repo and sync it to the actual state of the cluster. you define what "should be running" in git, and argo makes sure the cluster reflects that.

im not sure if i understand this well...

1. I have a mono repo.
2. when i push to master, gh workflow build and push my docker to ghcr, and update the helmfile's environment config with the appropriate tag
now what? how do i do the cd/deployment? argocd? how does argocd integrates?

Hello,
I've started looking at Helmfile for work (and am pretty excited TBH). Should I consider Helmfile to be API stable?

The current version is v1.1.2, the status section suggests that the project adheres to SemVer, and I've read: https://github.com/helmfile/helmfile/blob/main/docs/proposals/towards-1.0.md
However, the most recent item on the status page is 2022, and I have not found a canonical statement elsewhere that v1.1 is API-stable.

https://helmfile.readthedocs.io/en/stable/#status

This may seem a little fussy, but I will be challenged on this point if I propose that my company adopts Helmfile.

Hi, I am new to use helmfile. Does anyone know how to config the helmfile so that when I rebuild my chart image, my app will be restarted and pull the latest image? P.S: the image tag will not be changed when the image is rebuilt
or if I can redeploy one single app in the same release without tearing down all apps and the restart all apps?

hey, is it possible to apply a normal manifest as a resource in helmfile? specific usecase is pre-applying CRDs from manifests (typically URLs, like GatewayAPI CRDs) before all other releases

Hi everyone !
I recently had to fiddle with implementing the Scaleway provider for vals, here is a (very crude) first draft : https://github.com/Xide/vals/tree/feat/scaleway-secret-manager
I was wondering if you were open to the addition of this new provider upstream. If so, i think i can open the PR by the end of week (need some time to implement test & docs).
Thanks

Maybe I should focus more on Kustomize itself. It seems that a name is required but regex matching doesn't work for some reason.

I'm trying to get rid of all CustomResourceDefinition resources from helmfile template via patches. I think it should be possible with '$patch: delete' and a regex selector for the name of the CRD but helmfile errors out with a message that no resources can be found. If I use an exact name, it works. I'm using this patch:

  strategicMergePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      name: .*
    $patch: delete

Does helmfile work differently and does it not support regex matches on the name? If so, how do I target multiple resources with some kind of wildcard? I'm basing this on https://github.com/kubernetes-sigs/kustomize/blob/master/examples/patchMultipleObjects.md Also, it seems that name is somehow mandatory when using it with Helmfile but from the above link it seems that name is optional?

Hi,

I'm trying to understand how i can deploy different versions of charts to different environments.

For instance, I want to have a qa environment use a newer version of a chart for testing compatibility ahead of rolling the chart to a prod environment.

I've tried a few approaches, but i'm stuck trying to work it out.

The most sensible sounding approach (generated by AI i think) was; https://gurubase.io/g/helmfile/different-chart-versions-helmfile-environments where i pop;

releases:
  - name: myapp
    chart: stable/mychart
    version: {{ .Environment.Values.mychart.chartVersion }}

but every time i try and run helmfile build qa i get an error;

in ./helmfile.yaml: error during helmfile.yaml.part.1 parsing: template: stringTemplate:20:29: executing "stringTemplate" at <.Environment.Values.mychart.chartVersion>: map has no entry for key "mychart"

Has anyone got any suggestions on how to deal with per-env chart versioning?

Here attached some great resource for linux and kubernetes.

https://github.com/Pulkit12966/redhat_official_studyguide_RHCSA

hey hey everyone! I'm struggling a bit with using helmfile when deploying the opensearch chart, where I need to set the javaOpts to something like -Xms16g -Xmx16g. I put such value in each environment yaml (note: we use the value using the {{ .Environment.Values.openSearchJavaOpts }}), but when helmfile goes to deploy stuff, it translates our configuration as follows:

helm template ... --set opensearchJavaOpts=-Xms16g -Xmx16g

which obviously doesn't work as it interprets the part after the space as a shorthand flag for helm itself. I tried various ways to encode the value, hoping to be able to pass that whole string as a single value but nothing worked, the string is always unquoted during the helm template invocation, triggering the issue. Any ideas?

Thanks in advance for any suggestion 🙇

disclaimer: we are using forceNamespace: true as without it everything is deployed on the default namespace, which we don't want

@Ihor Urazov thanks so much. we will solve this issue.

@mumoshu @yxxhero congrats on reaching V1 milestone!

I want to stress importance of https://github.com/helmfile/helmfile/issues/1079, which I believe is a breaking bug for V1. Ideally it must be fixed to ensure smooth transition. Not ideally, but acceptable, is to properly document it in V1 release notes. Otherwise it's a very sneaky bug that will break end user regexes, potentially breaking chart deployments, due to incorrect regexes passed into.

Did https://github.com/mamezou-tech/setup-helmfile randomly stop working for anyone?

Are anyone using the hcl values in their stuff? Would be nice to have some example of a real world usage.

Are there any patterns or strategies I can use for a large helmfile to "retry" a failed install? If any single chart fails to install, the entire apply fails and you have to manually re-run it

Is there some clever way to hoist a release as a need of all other releases in the helmfile? Currently I'm manually adding it as a need to every release

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

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

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?

Hello, I had an inquiry about the demo-helmfile example:
• Catalog file
• Stack file
• Helmfile
My understanding is that the stack file pulls in the catalog file and then changes it to be of the "real" type. Then I believe that the helmfile gets included via the key/value pair "component: nginx". Some of the previous terminology may be off, but I think that's the general idea.

My inquiry is are the vars of the catalog entry supposed to be injected into the helmfile's nginx release? How mapping to the nginx release work and how are they picked up? Does it use the state-values-file? I noticed this empty values section in the helmfile. Is that related?

Hi again 🙂, trying to debug that when I run atmos helmfile apply what seems to be a correct kubeconfig gets generated as desired, but then I get failures by helm diff trying to connect via localhost.

Hey folks. Is there an appetite for this feature? https://github.com/helmfile/helmfile/discussions/178

Hi, Trying to figure out the data flow for Atmos + helmfile. How is, if it is, the generated ....helmfile.vars.yaml file supposed to be consumed? If it's not supposed to be consumed, what does it do?

👍️

Hi community. Here is a little contribution to promote helmfile. I like it more everyday, so I have written two posts. Let me know if you like it:
• https://medium.com/@pela2silveira/diving-deeper-into-helmfile-a3f77ba10d78
• https://medium.com/@pela2silveira/why-is-not-a-good-idea-to-manage-helm-releases-with-terraform-helmfile-is-a-better-fit-3fd8be60b8e4

Hi, follow-up question to ^. My understanding is that Atmos can run an EKS login command before running the helm commands. My question is: how do I specify which cluster and region in particular? Didn't see this info in the examples or docs, but maybe I just missed it. Thanks!

Maybe I'm just having trouble finding the setup docs, but where should helmfiles go in an atmos project? Are they a component?

Helmfile release 0.167.0 congratulations to everyone who helped out for this release

Hello, my Helmfile is version v0.144.0 and set-string: should be available since v0.144.0.
However, when I try to use it I get this error:

⨠ helmfile lint
in ./helmfile.yaml: failed to read helmfile.yaml: reading document at index 1: yaml: unmarshal errors:
  line 23: field set-string not found in type state.ReleaseSpec

I must be doing something wrong, but not sure what

Is there a way I can build a variable inside release scope before rendering it? Or create some kind of self-reference?

Hey I recently wrote this blog post on how painful it was to write a Helm Deployment and Kubernetes Objects using Go: https://theclouddude.co.uk/the-painful-journey-of-deploying-a-helm-chart-to-kubernetes-with-go

I've got a dependent chart with a helper file with:

{{- define "dep.environment" -}}
{{ (.Values.common | default (dict "envName" "DEFAULT")).envName }}
{{- end -}}

Which works super as long as .Values.common.envName has a value. I can't figure out a config that works when it doesn't have a value. The default never kicks in.

Have tried dig, and ((.Values.common).envName) | default "default") and a few other methods. In fact the example with default I just listed works if I move it into the deploy directly instead of the dependent chart. So what format works properly in a dependent chart, if any?

Hello, I created article integrating ory product with my K8S cluster and istio using helmfile, I would appreciate your feedback
https://hamzabouissi.github.io/posts/guardians_of_hell/

I was wondering, is using helmfile as a go api still supported? I could only find info about it in the old issue tracker.

Hi has anyone been able to use the helm client to deploy a helm chart with GO?
https://pkg.go.dev/github.com/mittwald/go-helm-client@v0.12.9

I'm trying to deploy an ingress-nginx chart no customization and it works when I use helm install even with a custom yaml file. But it doesn't work with the GO helm client.

I get context deadline exceeded

Are the replies in https://github.com/helmfile/helmfile/issues/277 still up to date? raw/incubator doesn't seem to be a thing anymore, but i'd like to avoid switching to something argocd/flux, so would be great to have something included
I just got strategicMergePatches working for existing resources at least, and it seems great so far