Generalized support for overwriting/extending initContainers, volumes, volumeMounts

[BWibo]

@gislab-augsburg, @klml, @eidottermihi, @MandanaMoshref:
Sorry this took me so long, but finally here is a first draft. It basically pics up what I suggest here. It should allow using OpenShift just by adapting the configuration when depolying the chart. Check out the examples below to see how it works.

This shall replace the work proposed in #31 with a more general and flexible mechanism to allow user of this chart to:

• Overwrite, or extend the default initContainer, volume, volumeMount of this chart
• Overwrite includes to disable the default initContainer, volume, volumeMount specified in this chart

What is different compared to the work in #31?

• The mechanism implemented here allows to freely configure initContainer, volume, volumeMount. This is at deploy time with helm -f values.yml or using helm --set. Thus, if any specific requirements arise in the future (e.g. have an additional file writable for OpenShift using a volume), this mean just a configuration change and not a new release of the chart.
  In Sddi urban 2.9.9: Changes for OpenShift deploy, further configurability and reduced dependencies #31, e.g. only specific files are replaced by volumes. The solution is specific for the issue of supporting OpenShift.
• The given defaults can be overwritten, disabled or extended.
• It is possible to use templates in the definitions. They need to be quoted!!

ToDos

• Implementation for initContainers
• Implementation for volumes
• Implementation for volumeMounts
• Add the above implementations in ckan-deployment too. Currently, it only in the Statefulset.
• Add documentation: Currently block due to: [Bug]: Segmentation violation when using templates in values.yml norwoodj/helm-docs#217

Requirements

• This might require Helm >= v3.14.0 what I used for testing.

Examples

Here are some example to illustrate usage of this. In all examples we create a custom values.yml files with our configuration for the deployment. The we run: helm install sddi sddi-ckan/sddi-ckan -f values.yml

Disable default initContainers

This will disable the default init containers.

values.yml:

ckan:
  initContainers: []

Replace default initContainers

This will overwrite the default init containers with the one specified below.

values.yml:

ckan:
  initContainers:
    - name: custom-init-data
      image: my/customimage:v1.2.3
      command: ["sh", "-c", "chown -Rv 999:999 /custom/path"]

Extend the default initContainers

This will extend the default init containers of the chart. Note: The template specified below will be rendered!

values.yml:

ckan:
  extraInitContainers:
    - name: additional-init-data
      image: my/customimage:v1.2.3
      command: ["sh", "-c", "chown -Rv 0:0 {{ .Values.persistence.storagePath }}"]

[BWibo]

@gislab-augsburg, @klml, @eidottermihi, @MandanaMoshref:
I would appreciate if you could test if this works on OpenShift. If your struggling to get the configuration right, let me know, I can help. We can setup a meeting too, if you need some further explanantion or assistance.

[klml]

@BWibo tnak you very much for your PR, we will test your solution the next week.

[gislab-augsburg]

@BWibo:
I tested your solution in LHM Openshift and it works like a charm :)
You are absolutely right, it is better than the changes proposed in #31, more flexible and general. With the ability to freely configure initContainers, volumes and volumeMounts, this feature solves all our issues and we are free to include further configMaps etc. if we will need some in the future. Thank you so much 🙏

I only had a minor issue on the first try with volume sizeLimit:

configuration in our values-lhm-tum.yaml:

  # Extra Volumes
  extraVolumes:
    # Volumes for paths that need to be writable
    - name: srv-app-i18n
      emptyDir:
      sizeLimit: 500Mi
    - name: srv-app-data
      emptyDir:
      sizeLimit: 500Mi

results in :

mb@nbo00370518:~/ckan-helm$ helm upgrade --install -f values-lhm-tum.yaml -f values-dev-secret-tum.yaml ckan ../tum-sddi/sddi-ckan-k8s/charts/sddi-ckan/
W0226 12:15:54.671209    1389 warnings.go:70] unknown field "spec.template.spec.volumes[1].sizeLimit"
W0226 12:15:54.671585    1389 warnings.go:70] unknown field "spec.template.spec.volumes[2].sizeLimit"
Release "ckan" has been upgraded. Happy Helming!
NAME: ckan
LAST DEPLOYED: Mon Feb 26 12:15:51 2024
NAMESPACE: udpkatalog-dev
STATUS: deployed
REVISION: 132
TEST SUITE: None

But I'm not sure if sizeLimit is really necessary, @klml what do you think, do we need it?

[BWibo]

@gislab-augsburg Thx for testing and really cool this works for you guys. I think there is a syntax error regarding the size level. There is one level of indention missing. This should do the trick:

  # Extra Volumes
  extraVolumes:
    # Volumes for paths that need to be writable
    - name: srv-app-i18n
      emptyDir:
        sizeLimit: 500Mi
    - name: srv-app-data
      emptyDir:
        sizeLimit: 500Mi

@gislab-augsburg Can you please confirm if this works?

As soon as this is done and we have a solution for #33, I'lll prepare a release.

[gislab-augsburg]

@gislab-augsburg Thx for testing and really cool this works for you guys. I think there is a syntax error regarding the size level. There is one level of indention missing. This should do the trick:

  # Extra Volumes
  extraVolumes:
    # Volumes for paths that need to be writable
    - name: srv-app-i18n
      emptyDir:
        sizeLimit: 500Mi
    - name: srv-app-data
      emptyDir:
        sizeLimit: 500Mi

@gislab-augsburg Can you please confirm if this works?

As soon as this is done and we have a solution for #33, I'lll prepare a release.

@BWibo Yes, it works :) You were right, it was just an indentation mistake. From our side, you can merge and prepare the release.

#33 is solved, did I get it right? From our side, there are no problems with solr when:

• using the branch feature/customVol-Mnt-Init
• overwriting ckan initContainers and so removing init-data in our values-lhm.yaml
• having the default podSecurityContext: {} in sddi-ckan-k8s/charts/sddi-ckan/charts/solr/values.yaml without changing this in our values-lhm.yaml
• not creating an initContainer for solr

[BWibo]

OK, cool. I'll create a beta release first for testing.
Yes #33 is resolved, but it should be tested. Let's do this in the beta release (#34) where all new features are included.