Enable Helm Template for the Pod affinity

[joachimBurket]

Details

Describe the solution you'd like:

Allow to use Helm Template for fields in the affinity block (e.g. defaultPodOptions.affinity).

Additional Information:

I like to set the podAntiAffinity on the hostname to avoid having two Pods of the same application running on the same hosts. Generally, I configure it like so:

[....]
podAntiAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
          - key: app
            operator: In
            values:
              - "my-app"
      topologyKey: kubernetes.io/hostname
  preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - "my-app"
        topologyKey: region
[....]

Enabling Helm Template for the affinity block would allow me to make this re-usable for all my applications, changing my-app by {{ Release.Name }}

[joachimBurket]

Huge thanks for your incredible work btw! 🙏

[joachimBurket]

Up 😉 (I'm open to do a PR if this feature seems useful to you)

[bjw-s]

Hi @joachimBurket, thanks for raising this enhancement! Sorry I haven't responded sooner 😊. I'm definitely not against implementing this somehow, but it might take some time/effort because currently the object gets passed as-is from the values into the underlying template.

[joachimBurket]

Hi! No worry! :)

What is in your opinion the best approach to make it templatable? I thought it would be possible to pass the entire object to the tpl Helm function (like done with the rawResource.spec object), but it seems it is harder than that 😅

[bjw-s]

There are two possible solutions:

• Create distinct fields for all the "official" fields under the podAntiAffinity key, add these to the schema, and add templating support where it makes sense
• As you already found: convert the value to a Yaml string under water, run the templating on that and then convert it back into the resource template yaml.

I would say that the first option would be the cleanest, but will also take a lot of work. The second option would be the quickest way to go though, so I am leaning towards that.

I'll see if I can get that going somewhere this week.

[joachimBurket]

Okay that's what I had in mind. I'd like to try to implement the first solution if you don't mind. That would allow me to better understand the library.

[bjw-s]

I've merged the "quick&dirty" version in v3.7.0 just now, but feel free to create a PR with the "nice" version if you are still up for it :)