authup/authup#3474 moves the image's writable directory from /usr/src/app/writable to /var/lib/authup (FHS location for mutable application state, and a cleaner mount point than a path nested in the install tree). The code default is unchanged — only the Dockerfile's WRITABLE_DIRECTORY_PATH moves.
The chart hardcodes the old path and sets no WRITABLE_DIRECTORY_PATH of its own, so it relies entirely on the image default. appVersion is currently 1.0.0-beta.62; the bump to the release carrying that change breaks the coupling.
Impact
charts/authup/templates/_server-env.tpl:
- L105 —
authup.server.volumeMounts mounts the writable emptyDir at /usr/src/app/writable - L110 — the provisioning configMap/secret mounts at
/usr/src/app/writable/provisioning
After the image bump the server reads provisioning from /var/lib/authup/provisioning, which nothing is mounted at. File-based provisioning silently stops being applied — the pod starts healthy, the configMap is still mounted and still checksum-annotated, and nothing in the log says the directory it scanned was empty. That is the sharp edge; it looks like a provisioning-content bug rather than a path bug.
Secondary: production log files land on the container's writable layer instead of the emptyDir. Harmless today since readOnlyRootFilesystem defaults to false, but it undermines the stated rationale for the mount ("the chart mounts emptyDirs at /usr/src/app/writable and /tmp to keep readOnlyRootFilesystem viable" — values.yaml L594, charts/authup/README.md L350), and anyone flipping that flag to true would get a server that cannot write its logs.
Suggested fix
Set WRITABLE_DIRECTORY_PATH explicitly in authup.server.env to whatever path the chart mounts, rather than inheriting the image default. That makes the chart immune to this class of change in either direction, so it keeps working across appVersion bumps and with a pinned older image alike — worth doing regardless of which path is chosen.
Then either keep /usr/src/app/writable (now explicit, so it works on both old and new images) or move the mounts to /var/lib/authup to match upstream. The second reads better next to an image that does the same, but the first is a smaller diff and equally correct once the env var is set.
Docs to follow: DESIGN.md L352, charts/authup/README.md L350, charts/authup/values.yaml L594, .agents/references/authup.md L14.
Upstream context
authup/authup#3474 moves the image's writable directory from
/usr/src/app/writableto/var/lib/authup(FHS location for mutable application state, and a cleaner mount point than a path nested in the install tree). The code default is unchanged — only theDockerfile'sWRITABLE_DIRECTORY_PATHmoves.The chart hardcodes the old path and sets no
WRITABLE_DIRECTORY_PATHof its own, so it relies entirely on the image default.appVersionis currently1.0.0-beta.62; the bump to the release carrying that change breaks the coupling.Impact
charts/authup/templates/_server-env.tpl:authup.server.volumeMountsmounts thewritableemptyDir at/usr/src/app/writable/usr/src/app/writable/provisioningAfter the image bump the server reads provisioning from
/var/lib/authup/provisioning, which nothing is mounted at. File-based provisioning silently stops being applied — the pod starts healthy, the configMap is still mounted and still checksum-annotated, and nothing in the log says the directory it scanned was empty. That is the sharp edge; it looks like a provisioning-content bug rather than a path bug.Secondary: production log files land on the container's writable layer instead of the emptyDir. Harmless today since
readOnlyRootFilesystemdefaults tofalse, but it undermines the stated rationale for the mount ("the chart mounts emptyDirs at /usr/src/app/writable and /tmp to keep readOnlyRootFilesystem viable" —values.yamlL594,charts/authup/README.mdL350), and anyone flipping that flag totruewould get a server that cannot write its logs.Suggested fix
Set
WRITABLE_DIRECTORY_PATHexplicitly inauthup.server.envto whatever path the chart mounts, rather than inheriting the image default. That makes the chart immune to this class of change in either direction, so it keeps working across appVersion bumps and with a pinned older image alike — worth doing regardless of which path is chosen.Then either keep
/usr/src/app/writable(now explicit, so it works on both old and new images) or move the mounts to/var/lib/authupto match upstream. The second reads better next to an image that does the same, but the first is a smaller diff and equally correct once the env var is set.Docs to follow:
DESIGN.mdL352,charts/authup/README.mdL350,charts/authup/values.yamlL594,.agents/references/authup.mdL14.Upstream context
WRITABLE_DIRECTORY_PATH=/usr/src/app/writableescape hatch for staying on the old location):docs/src/guide/deployment/upgrading.md