Add spec.volumeName: pvc-e7c56db2-481d-40cb-b94a-b264b7b4b5be to kubernetes/apps/gitea/pvc.yaml, with a comment on why it must stay.
Why
After #1116 merged, the gitea Kustomization went Ready=False at about 21:28Z: PersistentVolumeClaim "data-gitea-0" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests .... The diff shows VolumeName: "pvc-e7c5…" -> "".
The live claim's managedFields show kustomize-controller (Apply, 2026-09-23) owning spec.volumeName, because the namespace move pre-created this claim with volumeName (eb23d3ac, #878). #1116 left the field out, so server-side apply tries to remove an owned field, and the API server rejects the change. Neither my lint nor the review compared the manifest with managedFields.
Impact now
The apply fails before it writes anything. The live claim is unchanged (40Gi, bound, gitea-0 Running) and nothing was restarted. The gitea Kustomization applies nothing else until this merges.
Verified
kustomize build kubernetes/apps/gitea renders the claim with volumeName and 60Gi. Every field kustomize-controller owns (label, accessModes, storage, storageClassName, volumeMode, volumeName) is in the manifest. All of them equal the live values except resources.requests.storage, which is the one field allowed to change.
Linted only. A server-side dry-run needs write access, which atlas-bot does not have.
Gitea volume before resize (21:28Z, kubelet volume stats = statfs of the mount)
size 39.2 GiB, used 36.6 GiB, avail 2.6 GiB.
Revert
Revert this commit, or revert #1116 together with it. Without volumeName the Kustomization fails again. With both reverted, the claim stays at its current size and Flux stops managing it.
## What
Add `spec.volumeName: pvc-e7c56db2-481d-40cb-b94a-b264b7b4b5be` to `kubernetes/apps/gitea/pvc.yaml`, with a comment on why it must stay.
## Why
After #1116 merged, the gitea Kustomization went Ready=False at about 21:28Z:
`PersistentVolumeClaim "data-gitea-0" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests ...`. The diff shows `VolumeName: "pvc-e7c5…" -> ""`.
The live claim's managedFields show `kustomize-controller` (Apply, 2026-09-23) owning `spec.volumeName`, because the namespace move pre-created this claim with volumeName (eb23d3ac, #878). #1116 left the field out, so server-side apply tries to remove an owned field, and the API server rejects the change. Neither my lint nor the review compared the manifest with managedFields.
## Impact now
The apply fails before it writes anything. The live claim is unchanged (40Gi, bound, gitea-0 Running) and nothing was restarted. The gitea Kustomization applies nothing else until this merges.
## Verified
- `kustomize build kubernetes/apps/gitea` renders the claim with volumeName and 60Gi. Every field kustomize-controller owns (label, accessModes, storage, storageClassName, volumeMode, volumeName) is in the manifest. All of them equal the live values except `resources.requests.storage`, which is the one field allowed to change.
- Linted only. A server-side dry-run needs write access, which atlas-bot does not have.
## Gitea volume before resize (21:28Z, kubelet volume stats = statfs of the mount)
size 39.2 GiB, used 36.6 GiB, avail 2.6 GiB.
## Revert
Revert this commit, or revert #1116 together with it. Without volumeName the Kustomization fails again. With both reverted, the claim stays at its current size and Flux stops managing it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
#1116 left spec.volumeName out of pvc.yaml. kustomize-controller has owned
that field since the namespace move pre-created the claim (eb23d3ac), so
server-side apply tried to clear it and the API server rejected the claim
as an immutable-spec change. The gitea Kustomization is Ready=False and the
claim stays at 40Gi. Pin volumeName to the live value.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Approved on d2ee7a09. Premise: Kustomization gitea Ready=False since 21:28:14Z, error is VolumeName pvc-e7c56db2… -> "" (immutable spec). Live data-gitea-0 managedFields: kustomize-controller (Apply) owns labels/app.kubernetes.io/name, accessModes, resources.requests.storage, storageClassName, volumeMode, volumeName. Rendered pvc.yaml (no transformers in kustomization.yaml) equals live on all of them except storage 40Gi->60Gi. ceph-block allowVolumeExpansion: true, reclaim Retain (git). Revert: plain revert, no data effect.
Approved on d2ee7a09. Premise: Kustomization gitea Ready=False since 21:28:14Z, error is VolumeName pvc-e7c56db2… -> "" (immutable spec). Live data-gitea-0 managedFields: kustomize-controller (Apply) owns labels/app.kubernetes.io/name, accessModes, resources.requests.storage, storageClassName, volumeMode, volumeName. Rendered pvc.yaml (no transformers in kustomization.yaml) equals live on all of them except storage 40Gi->60Gi. ceph-block allowVolumeExpansion: true, reclaim Retain (git). Revert: plain revert, no data effect.
Ghost
merged commit 77c8566c5b into master2026-10-03 21:30:32 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ghost
What
Add
spec.volumeName: pvc-e7c56db2-481d-40cb-b94a-b264b7b4b5betokubernetes/apps/gitea/pvc.yaml, with a comment on why it must stay.Why
After #1116 merged, the gitea Kustomization went Ready=False at about 21:28Z:
PersistentVolumeClaim "data-gitea-0" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests .... The diff showsVolumeName: "pvc-e7c5…" -> "".The live claim's managedFields show
kustomize-controller(Apply, 2026-09-23) owningspec.volumeName, because the namespace move pre-created this claim with volumeName (eb23d3ac, #878). #1116 left the field out, so server-side apply tries to remove an owned field, and the API server rejects the change. Neither my lint nor the review compared the manifest with managedFields.Impact now
The apply fails before it writes anything. The live claim is unchanged (40Gi, bound, gitea-0 Running) and nothing was restarted. The gitea Kustomization applies nothing else until this merges.
Verified
kustomize build kubernetes/apps/gitearenders the claim with volumeName and 60Gi. Every field kustomize-controller owns (label, accessModes, storage, storageClassName, volumeMode, volumeName) is in the manifest. All of them equal the live values exceptresources.requests.storage, which is the one field allowed to change.Gitea volume before resize (21:28Z, kubelet volume stats = statfs of the mount)
size 39.2 GiB, used 36.6 GiB, avail 2.6 GiB.
Revert
Revert this commit, or revert #1116 together with it. Without volumeName the Kustomization fails again. With both reverted, the claim stays at its current size and Flux stops managing it.
🤖 Generated with Claude Code
Approved on
d2ee7a09. Premise: Kustomization gitea Ready=False since 21:28:14Z, error is VolumeName pvc-e7c56db2… -> "" (immutable spec). Live data-gitea-0 managedFields: kustomize-controller (Apply) owns labels/app.kubernetes.io/name, accessModes, resources.requests.storage, storageClassName, volumeMode, volumeName. Rendered pvc.yaml (no transformers in kustomization.yaml) equals live on all of them except storage 40Gi->60Gi. ceph-block allowVolumeExpansion: true, reclaim Retain (git). Revert: plain revert, no data effect.