Pre-upgrade migration Job mounts release ConfigMaps that do not exist when the hook runs

[tada5hi]

Found while auditing PR #16. Pre-existing on master, not introduced there.

Problem

authup.server.volumeMounts / authup.server.volumes (templates/_server-env.tpl) are shared verbatim by the server Deployment and the pre-upgrade migration Job (templates/server/migration-job.yaml). They include the provisioning volume (ConfigMap <fullname>-server-provisioning, or a Secret) and the configuration volume (<fullname>-server-configuration).

Both of those are plain release resources with no hook annotations, and helm applies pre-upgrade hooks before the release manifest. So on the first helm upgrade that enables server.provisioning.files (or server.configuration) together with server.migration.enabled, the hook pod references a ConfigMap that does not exist yet: the pod sits in ContainerCreating with configmap ... not found and the upgrade blocks until the hook times out.

Steady-state upgrades are fine, because the ConfigMap already exists from the previous release. It is specifically the upgrade that introduces the value.

Why it is not obvious

The sharing is deliberate and load-bearing (architecture rule 10: the Job and the Deployment must not drift). The mount list is simply wider than the Job needs.

Suggested fix

The migration Job runs server/core migration run, which does not read provisioning files or the config file. Give the Job its own narrower mount set (writable + tmp only), or gate the provisioning/configuration entries on a flag the Job passes as false, keeping the env map shared as rule 10 requires.

A test for it: install with provisioning disabled, then helm upgrade enabling server.provisioning.files and server.migration.enabled in the same operation.