#helmfile (2023-11)

I understand that it’s a helm-diff issue though, not a Helmfile one.

@Tom Janson do you mind to create a issue for that issue?

I’d be happy to — but should I? Considering it’s a helm-diff issue that’s outside the scope of Helmfile?

It may be an option to let other helmfile users know that

• the problem is aсknowledged

• an issue is in helm-diff, not in helmfile itself.

created issue here: https://github.com/helmfile/helmfile/issues/1122

How much memory does your “same thing” consumes on your VM ?

This is simple deployment using helmfile sync Value is differnet every time

Question is more about: how disk and CPU could lead to increased memory usage during helmfile sync execution? What can cause this?

I need a way to add a sequence number to a resource in each chart to capture the order in which they were installed. The creation timestamp isn’t granular enough

Bump: is there some clever way to set a deterministic sequence number on charts installed by helmfile that represents the DAG order?

Don’t override namespace via cli arg while installing this particular release. It may be achieved using selectors.

I want helmfile not to touch the dev releases when updating the live releases and vice versa

but having the values in all environments feels like duplicate information.. Ideally I would want to just say something like condition: {{ eq .Environment.Name "live" }} but that doesn’t work since the key name needs to be enabled

@Tim I never saw inherit and condition settings in helmfile. Where did you find that fields in helmfile docs?

I want helmfile not to touch the dev releases when updating the live releases and vice versa

I’d say you need

but it seem better way would be like that

Thanks a lot for your detailed response, will give it a try. I found those values in the docs, inherit and condition

Unfortunately your suggestion doesn’t solve the issue that helmfile will destroy releases when doing a helmfile sync. For me it is not about setting env values but having releases defined that will be updated when a specific environment is selected and other releases will not be touched during that update

well your first suggestion actually does but I did not want to add templating into the helmfile because I thought I could do it with the condition field.. There might be a way but I can’t see it though..

If you only want to use the environment to drive releases you will need to do some templating:

environments:
  default: # developers and jenkins commit deployments
  live: # jenkins only, live deployments
---
templates:
  default:
    chart: ./chart

values:
  - live:
      enabled: {{ eq .Environment.Name "live" }}
  - default:
      enabled: {{ not (eq .Environment.Name "live") }}

---
releases:
  - name: dev-release
    condition: default.enabled
    inherit:
      - template: default

  - name: live-release
    condition: live.enabled
    inherit:
      - template: default

Or you could use a label and selector. So for example, instead of the condition you could add a label:

releases:
  - name: dev-release
    labels:
      live: false
    inherit:
      - template: default
  - name: live-release
    labels:
      live: true
    inherit:
      - template: default

And then run Helmfile with ---selector live=true to only update the live releases.

Thanks, that looks good! Is there a reason why I can not use essentially the environments as selectors? I already have that information in the environment selection, duplicating it in the selector seems redundant.. I guess templating will have to do then..

@Tim AFAIK not implicitly. You’d need to pass the environment again as a selector, e.g. helmfile -e live --selector environment=live

alright, thanks a lot, the templating approach works just fine and looks very clean!