"Extra"/Bonus manifests

[theangryangel]

For more customised installations it would be convenient to support "extra" manifests within the chart.

Examples include:

• CustomerA who has a queue_job-like kafka runner (currently we have used helm to template the project), which means we have lost the click-odoo-update support
• CustomerB who has lots of extra ingresses

Questions:

1. How do other helm charts deal with this?
2. Should the helm chart deal with this?
3. If not what are the other solutions.

[theangryangel]

Ok splitting this out into a few categories:

1. Sidecars: currently we do not care about these. We should add support into the helm chart at some point. But not now.
2. Extra ingresses, or other non-deployment/statefulsets/pods: Easiest way looks to be to manually create manifests for them. We just point flux at them in the usual way, nothing special needed.
3. Extra deployments: The only problematic issue with following point 2 is the rolling of deployments when configmaps, etc. change. Helm currently manages this for us. Short of depending on third party operators to manage this (which would be problematic with upgrades, etc.) we should probably just allow for extraManifests in the helm chart for now and pass that through

[dnplkndll]

do you have any examples on the string format expected here?

use case a post-upgrade,post-install job with click-odoo.

https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/assets/auto-deploy-app/values.yaml#L316
I was expecting something like this to work. not sure on the template expansion expression like the env are needed. ( tried string quoted with extraManifests: | as well)

desired: job created on install/update in case DB was replaced.
actual:
Error: failed to parse .gitlab/auto-deploy-values.yaml: error converting YAML to JSON: yaml: line 153: did not find expected key
or Error: template: odoo/templates/extra.yaml:2:3: executing "odoo/templates/extra.yaml" at <tpl>: wrong number of args for tpl: want 2 got 1

extraManifests:
  - apiVersion: batch/v1
    kind: Job
    metadata:
      name: sanitizing-database
      annotations:
        "helm.sh/hook": post-upgrade,post-install
        "helm.sh/hook-delete-policy": before-hook-creation
        "helm.sh/hook-weight": "6"
    spec:
      template:
        metadata:
          name: sanitizing-database
        spec:
          restartPolicy: Never
          containers:
          - name: sanitizing-database-cont
            image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default "latest" }}"
            env: {{- include "odoo.common.env" . | nindent 10 }}
            command:
              - "/bin/bash"
            args:
              - "-c"
              - |
                /opt/odoo/common/entrypoint
                if [ "$( psql -XtAc "SELECT 1 FROM pg_database WHERE datname='$PGDATABASE'" )" = '1' ]
                then
                  echo "Database $PGDATABASE exists, running click-odoo"
                  echo "[+] Sanitizing database (Python)"
                  click-odoo -d "$restore_db_name" /opt/odoo/custom/src/private/sanitize.py
                else
                  echo "Database $PGDATABASE does not exist, skipping click-odoo-upgrade"
                fi

[theangryangel]

It's not actually ever gone into use. Looking at it, it's broken, sorry about that. I'll figure out getting a patch/fix out sometime over the next few days.

[theangryangel]

I've raised #58 and I'll get one of the team to review today/first thing tomorrow.