3

I created a new chart with 2 podPresets and 2 deployments and when I go to run helm install the deployment(pod) object is created first and then podPresets hence my values from podPreset are not applied to the pods, but when I manually create podPreset first and then deployment the presets are applied properly, Is there a way I can specify in helm as to which object should be created first.

Nikhil Soni
  • 1,011
  • 1
  • 11
  • 23

2 Answers2

2

Posting this as Community Wiki for better visibility as answer was provided in comments below another answer made by @Rastko.

Pod Presets

A Pod Preset is an API resource for injecting additional runtime requirements into a Pod at creation time. Using a Pod Preset allows pod template authors to not have to explicitly provide all information for every pod. This way, authors of pod templates consuming a specific service do not need to know all the details about that service.

For more information, please check official docs.

Order of deploying objects in Helm

Order of deploying is hardcoded in Helm. List can be found here.

In addition, if resource is not in the list it will be executed as last one.

Answer to question from comments*

Answer to your question - To achieve order different then default one, you can create two helm charts in which one with deployments is executed afterwards with preinstall hook making sure that presets are there.

Pre-install hook annotation allows to execute after templates are rendered, but before any resources are created.

This workaround was mentioned on Github thread. Example for service:

apiVersion: v1
kind: Service
metadata:
  name: foo
  annotations:
    "helm.sh/hook": "pre-install"

As additional information, there is possibility to define weight for a hook which will help build a deterministic executing order.

  annotations:
    "helm.sh/hook-weight": "5"

For more details regarding this annotation, please check this Stackoverflow qustion.

Alberto Chiusole
  • 2,204
  • 2
  • 16
  • 26
PjoterS
  • 12,841
  • 1
  • 22
  • 54
1

Since you are using Helm charts and have full control of this part, why not make optional parts in your helm charts that you can activate with an external value?

This would be a lot more "Helm native" way:

{{- if eq .Values.prodSecret "enabled"}}
      - name: prod_db_password
        valueFrom:
          secretKeyRef:
            name: prod_db_password
            key: password
{{- end}}

Then you just need to add --set prodSecret=enabled when executing your Helm chart.

Rastko
  • 477
  • 2
  • 7
  • Hey @Rastko I am sorry but I don't think this will solve the issue, I have a PodPreset object with some EVN variables that need to be injected into some Pods, now since helm chart creates the Pod object first then the PodPreset object the ENV variables from PodPreset will not be injected into Pod, so I wanted to knwo is there any way to tell helm chart which obejct to create first – Nikhil Soni Nov 24 '19 at 07:23
  • 1
    Answer to your question - To achieve order different then default one, you can create two helm charts in which one with deployments is executed afterwards with preinstall hook making sure that presets are there. – Rastko Nov 24 '19 at 07:35
  • You can see Helm install and uninstall order here: https://github.com/helm/helm/blob/release-2.10/pkg/tiller/kind_sorter.go#L61 – Rastko Nov 24 '19 at 07:37
  • I still think that conditional based on external value covers your problem well - just add what you want to inject as conditionally deployed env vars, so you do not even have to inject, you use flags you set to decide which env vars are in deployment. – Rastko Nov 24 '19 at 07:39
  • I think I get your point now i.e.to wrap ENV variables in condition statement and override the condition based on the needs, It's just I was reading about PodPresets and wanted to use them here hence this specific requirement. – Nikhil Soni Nov 24 '19 at 08:17
  • Exactly, I believe templating nature of Helm actually makes it natural to wrap multiple things in conditionals and choose what you want to deploy, rather then injecting after deployment. – Rastko Nov 24 '19 at 10:42