{{- if .Values.database.enabled }} # AddonClaim — declara la intencion de la app de tener una BD (default MariaDB). # Lo materializa addon-provisioner (CRD idp.coralware.cloud/v1alpha1): # - reconcilia este claim cada RECONCILE_INTERVAL (default 300s) por TenantProfile. # - crea BD logica + user + grant via Job DDL efimero en el cluster tenant. # - publica el Secret `{{ .Values.database.secretName }}` en este ns (`apps`) # con DATABASE_URL / DATABASE_HOST / DATABASE_PORT / DATABASE_USER / # DATABASE_PASSWORD / DATABASE_NAME (contrato §2.3 del OpenSpec). # # Ordering con los hooks del chart (clave para que Alembic encuentre el Secret): # weight -10 (este AddonClaim) # -> weight -5 (ServiceAccount) # -> weight 0 (Job Alembic — espera al Secret via InitContainer wait-for-secret) # # delete-policy: NO se declara intencionalmente. # - Asi el AddonClaim sobrevive entre `helm upgrade` (re-apply idempotente). # - Evita disparar el finalizer `cleanup-logical` en cada upgrade (que dropearia # el user y regeneraria el password, causando ventana de downtime). # - Trade-off documentado: `helm uninstall` deja el AddonClaim orfano y MariaDB # sigue aprovisionada. Es coherente con `deletionPolicy: Retain` (default): # borrar BD productiva debe ser decision explicita, no side-effect del uninstall. # Cleanup explicito: `kubectl delete addonclaim {{ .Release.Name }}-db -n apps`. apiVersion: idp.coralware.cloud/v1alpha1 kind: AddonClaim metadata: name: {{ .Release.Name }}-db labels: {{- include "app.labels" . | nindent 4 }} annotations: "helm.sh/hook": pre-install,pre-upgrade "helm.sh/hook-weight": "-10" spec: addonType: {{ .Values.database.addonType | default "mariadb" | quote }} databaseName: {{ .Values.database.databaseName | default (printf "%s_db" (.Release.Name | replace "-" "_")) | quote }} user: permissions: {{ .Values.database.user.permissions | default "rw" | quote }} secretName: {{ .Values.database.secretName | quote }} deletionPolicy: {{ .Values.database.deletionPolicy | default "Retain" | quote }} {{- end }}