init-migration job not being created for helm upgrade --install command.

[rajshrestha86]

Consider a helm release where we are introducing kong after some time. In that case helm upgrade --install command will set .Relase.IsUpgrade and not .Release.IsInstall, but migration job is only created on helm install according to this.

{{- if .Release.IsInstall -}}
{{/* .migrations.init isn't normally exposed in values.yaml, since it should
     generally always run on install--there should never be any reason to
     disable it, and at worst it's a no-op. However, https://github.com/helm/helm/issues/3308
     means we cannot use the default function to create a hidden value, hence
     the workaround with this $runInit variable.
 */}}
{{- $runInit := true -}}
{{- if (hasKey .Values.migrations "init") -}}
  {{- $runInit = .Values.migrations.init -}}
{{- end -}}

{{- if (and ($runInit) (not (eq .Values.env.database "off"))) }}
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ template "kong.fullname" . }}-init-migrations

Shouldn't there be a way to create migration job for helm upgrade command for a newly installed kong instance?

[andrewgkew]

@rajshrestha86 the init migration job runs the bootstrap command for the database, and so should only happen when the kong release is installed not upgraded. Bootstrap can only be run once otherwise you have to wipe all the data in the database.

What use case are you suggesting is needed to run the bootstrap of the database for an already installed Kong release?