#helmfile (2021-06)

Hey! Your contribution is always welcomed but
with a secret engine of none I couldn’t understand this part.

Probably you can share me a imaginary configuration that you’ll write after your suggested helmfile improvement, so that I can better see your goal?

Actually after some research I think I was simply expecting secrets functionality in helmfile to operator differently than it does. figuring out --supress-secrets literally supresses kubernetes secrets objects output and nothing else

--supress-diff is the best available to me right now for not logging secrets to CI/CD

or I could just go with a sync to produce no output as well i suppose

one thing I also tried was using the remote secrets stuff via vals. They have a format secretref+... which takes the sensitivity of the infromation into account when displaying

secretref+file://<file> , but helmfile does not appear to notice or care about this , although it does load the data fine enough in plain text

Do you think its possible we could determine via vals if the data came from secretrefs and block it from output ?

that will require a lot of refactoring and development effort

What do you mean by a release secret file? Can you provide a code example?

I amtalking about this file

But where is that coming from? Could share some code example? That looks like coming from falco

this release file? It is deployed by helmfile. what kind of code example you would like to see. it can reproduce with any type of charts. if it fails to deploy sometimes it left the release file and next time when you run helmfile it will check the release file and won’t find any changes so won’t deploy it to the cluster and will miss. On that time we delete this release file and apply again.

Unfortunately, it isn’t clear to me what is the issue and how to tackle. Maybe @mumoshu have more insights

I see helmfile already created the “release” secret file Are you talking about the fact that helm creates a release secret containing the release info, on install?

Helmfile doesn’t touch it. Perhaps you just want to set releases[].atomic to true in helmfile.yaml to prevent helm from creating the release on failed install.

thanks, I would like that. going to try it.

Using your own values.yaml file is no problem, but if you want to add templates and modify the chart, you either have to copy it, or use something like kustomize to modify just the parts of the chart that you want instead

You can use JSON/Strategic-Merge patches directly in Helmfile, see https://github.com/roboll/helmfile#highlights and https://github.com/roboll/helmfile/pull/673

I take the approach of putting my dependencies or extra config either in a local helm chart, or using the incubator/raw chart (if it’s a very simple thing) and using labels and “needs” to group the releases.

For example, I deploy the istio-operator with an upstream helm chart, and deploy the custom resource as another helm release: istio-config (using the incubator/raw chart). I specify that the istio-config release needs the istio-operator release and add an arbitrary label app: istio to the releases (in the helmfile). You can then do something like helmfile -e dev -l app=istio sync

it actually doesn’t even work if i mimic the tests in helmfile repo… I still get empty output from template

https://github.com/roboll/helmfile/issues/1889

Sometimes just writing this stuff out helps… just thought of another solution… duplicate entries in the inline values section for each release… e.g. using my-app-a twice below

releases:
  - name: myRelease
  values:
    - my-app-a:
        {{ tpl (readFile "common.yaml.gotmpl") . | nindent 8 }}
    - my-app-a:
         theCommonThing:
            mySpecialThing: myOverridenValue

I had to helm delete cert-manager-issuers && helmfile apply. The solution doesn’t seem all that, um, eloguent.

I think the root cause of the issues, is that the certmanager-webhook is not yet available, and there needs to be a delay in deploying this.

Yes, to mitigate this we are doing

...
- events: ["postsync"]
  showlogs: true
  command: "sleep"
  args: ["30s"]
...

in cert-manager release definition and then for the cluster-issuer release we define a dependency:

...
needs:
  - cert-manager/cert-manager
...

Yes, we recommend the same thing

I had some time this week to replace simple sleep w/ some heuristic, f.e. w/ some old version of vault-operator

    hooks:
      # let's get some time to vault-operator to push CRDs into k8s, or vault-catalog will fail
      # the idea is to
      # 1) wait till all CRDs will be pushed to k8s api - bash cycle
      # 2) wail till all these CRDs will be completely parsed by k8s api - kubectl wait
      - events: [ "postsync" ]
        showlogs: true
        command: "bash"
        args:
          - -c
          - >
            TARGET=16;
            CRDs=0;
            LABEL="app=kubevault";
            while [[ $CRDs -lt $TARGET ]]; do
            sleep 1;
            CRDs=$(kubectl --context {{`{{.Release.KubeContext}}`}} get crd -l $LABEL|wc -l|tr -d ' ');
            echo "CRD amount=$CRDs, target=$TARGET";
            done;
            RET=1;
            while [[ $RET -ne 0 ]]; do
            kubectl --context {{`{{.Release.KubeContext}}`}} wait --for condition=established --timeout=120s -l $LABEL crd;
            RET=$?;
            done