Found while auditing PR #20. Pre-existing on master, not introduced there.
Problem
authup.server.fullname is trunc 52 of the base plus -server (max 59 chars), and templates/server/migration-job.yaml names the Job %s-migration, so the Job name reaches 69 characters.
A Job's metadata.name passes name validation (DNS subdomain, 253), but when spec.selector is not set by hand the registry strategy copies the name into the pod-template labels job-name / batch.kubernetes.io/job-name. A label value is capped at 63 characters, so the Job is rejected at create time.
Because the Job is a pre-upgrade hook, the failure mode is a helm upgrade that hangs until the hook timeout, on any release whose name is long enough and which has server.migration.enabled=true.
Reproduce:
helm template aaaa-bbbbbbbbbb-cccccccccc-dddddddddd-eeeeeeeeee-fg charts/authup \
--set server.migration.enabled=true -s templates/server/migration-job.yaml | grep '^ name:'
# -> aaaa-bbbbbbbbbb-cccccccccc-dddddddddd-eeeeeeeeee-fg-server-migration (68 chars)
Helm caps release names at 53, so 69 is the worst case.
Why it is not obvious
Architecture rule 9 (trunc 52 before suffixing) exists precisely to stop long release names collapsing resources onto one name, and it does that job. What it does not account for is that one resource kind has a 63-character ceiling rather than 253, and it is the only one whose suffix is added a second time (-server then -migration).
Suggested fix
| trunc 63 | trimSuffix "-" on the Job name, or a tighter trunc on the base for this one resource. Renaming is safe: the Job is a hook, recreated on every upgrade, and any install currently in this range is already broken.
Worth checking the same ceiling against the other component names while in there (-admin-console reaches 66), even though Deployments and Services are not label-value constrained the same way.
Related
The new hook-scoped ConfigMap from #20 is not affected: 83 characters at the maximum release name, well under the 253-character limit for a ConfigMap, and it cannot collide with <fullname>-configuration.
Found while auditing PR #20. Pre-existing on master, not introduced there.
Problem
authup.server.fullnameistrunc 52of the base plus-server(max 59 chars), andtemplates/server/migration-job.yamlnames the Job%s-migration, so the Job name reaches 69 characters.A Job's
metadata.namepasses name validation (DNS subdomain, 253), but whenspec.selectoris not set by hand the registry strategy copies the name into the pod-template labelsjob-name/batch.kubernetes.io/job-name. A label value is capped at 63 characters, so the Job is rejected at create time.Because the Job is a pre-upgrade hook, the failure mode is a
helm upgradethat hangs until the hook timeout, on any release whose name is long enough and which hasserver.migration.enabled=true.Reproduce:
Helm caps release names at 53, so 69 is the worst case.
Why it is not obvious
Architecture rule 9 (
trunc 52before suffixing) exists precisely to stop long release names collapsing resources onto one name, and it does that job. What it does not account for is that one resource kind has a 63-character ceiling rather than 253, and it is the only one whose suffix is added a second time (-serverthen-migration).Suggested fix
| trunc 63 | trimSuffix "-"on the Job name, or a tightertruncon the base for this one resource. Renaming is safe: the Job is a hook, recreated on every upgrade, and any install currently in this range is already broken.Worth checking the same ceiling against the other component names while in there (
-admin-consolereaches 66), even though Deployments and Services are not label-value constrained the same way.Related
The new hook-scoped ConfigMap from #20 is not affected: 83 characters at the maximum release name, well under the 253-character limit for a ConfigMap, and it cannot collide with
<fullname>-configuration.