Support custom labels for controlPlane's job

[esparta86]

Component(s)

controlplane, helm

Is your feature request related to a problem? Please describe.

My company uses Istio mesh, so we usually use labels in the namespace to inject the sidecar istio proxy in each pod. helm installs or upgrades are failing since istio-proxy are injecting in pods from Jobs. because the pods don't finish in a completed state.

Describe the solution you'd like

if jobs support custom labels, I am going to have more control which labels are injecting on Job Pods. It will also help to identify attributes of objects that are meaningful and relevant. also I can tell to istio controller to don't inject istio-sidecar

Describe alternatives you've considered

This is my proposal solution. You will notice that I added a new variable called customLabelsJobsControplane

# The otelcollector provides the necessary database schema for the migration
{{- if .Values.global.otelcollector.enabled }}
apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ include "controlplane.fullname" . }}-clickhouse-migration-{{ now | unixEpoch }}"
  labels:
    {{- include "controlplane.labels" . | nindent 4 }}
    {{- if .Values.customLabelsJobsControplane }}{{ toYaml .Values.customLabelsJobsControplane | nindent 4 }}{{- end }}
  annotations:
    # Run migration job before helm install/upgrade
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
    # Less priority than the migration job so the secret is created before the migration job
    "helm.sh/hook-weight": "-5"
    # Support for k14s.io. This annotation ensure that the job is run after clickhouse deployment
    {{- if .Values.global.clickhouse.enabled }}
    kapp.k14s.io/change-rule.clickhouse: "upsert after upserting cosmo.apps.clickhouse.wundergraph.com/deployment"
    {{- end }}
    {{- if .Values.global.otelcollector.enabled }}
    kapp.k14s.io/change-rule.otelcollector: "upsert after upserting cosmo.apps.otelcollector.wundergraph.com/deployment"
    {{- end }}
    # Create a new change-group so the controlplane can be deployed after the clickhouse migration
    kapp.k14s.io/change-group: "cosmo.apps.controlplane.wundergraph.com/ch-migration"
spec:
  backoffLimit: 10
  parallelism: 1
  template:
    metadata:
      name: "{{ include "controlplane.fullname" . }}-clickhouse-migration"
      labels:
        {{- include "controlplane.labels" . | nindent 8 }}
        {{- if .Values.customLabelsJobsControplane }}{{ toYaml .Values.customLabelsJobsControplane | nindent 8 }}{{- end }}
    spec:
      restartPolicy: OnFailure
      {{- with .Values.imagePullSecrets }}
      imagePullSecrets:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      containers:
        - name: seed
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ include "controlplane.image" . }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
            - name: CLICKHOUSE_DSN
              valueFrom:
                secretKeyRef:
                  name: {{ include "controlplane.secretName" . }}
                  key: clickhouseMigrationDsn
          args:
            - "/app/dist/bin/ch-migrate.js"
{{- end }}

Additional context

No response

[github-actions[bot]]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible. The roadmap is driven by our customers and we have to prioritize issues that are important to them. You can influence the priority by becoming a customer. Please contact us here.

[StarpTech]

Hi @esparta86 thanks for the report. We'll take a deeper look and come back. Would you be open to create a PR after we have agreed on a solution?

[esparta86]

of course, I made those changes in my local and tested it. let me know when you have an agreement solution.