fix(flux): no pruning in the Kustomizations that hand objects to new owners (restore-test stack 0/10) #1307

2026-10-17T20:23:41Z

claude-bot commented

2026-10-17 20:23:41 +00:00

Part 0 of the restore-test stack (parts 0–10, each based on the previous one; merge in order). It replaces #1297–#1305, which were rebased onto current master and changed after review.

Parts 4, 5, 6 and 8 move objects between Kustomizations. Flux's garbage collection deletes an object dropped from a Kustomization's source when the owner labels on the live object (kustomize.toolkit.fluxcd.io/name/namespace) still name that Kustomization. Those labels belong to whichever Kustomization applied the object last (kustomize-controller v1.9.6 deleteObjects, fluxcd/pkg/ssa v0.76.2 manager_delete.go), so "add first, then remove" is not safe either.

This PR sets prune: false on the nine Kustomizations that hand objects over: infrastructure, infrastructure-crds, home-assistant, authentik, immich, matrix, paperless, trmnl, woodpecker. They then drop the moved objects from their inventory without deleting them, and the new owners adopt them. Part 10 turns pruning back on.

Rollout: merge, check that the nine Kustomizations reconciled this revision (flux get ks), then go on with part 1. Until part 10, objects deleted from these nine Kustomizations stay in the cluster; the stack itself deletes none.

🤖 Generated with Claude Code

Part 0 of the restore-test stack (parts 0–10, each based on the previous one; merge in order). It replaces #1297–#1305, which were rebased onto current master and changed after review. Parts 4, 5, 6 and 8 move objects between Kustomizations. Flux's garbage collection deletes an object dropped from a Kustomization's source when the owner labels on the live object (`kustomize.toolkit.fluxcd.io/name`/`namespace`) still name that Kustomization. Those labels belong to whichever Kustomization applied the object last (kustomize-controller v1.9.6 `deleteObjects`, fluxcd/pkg/ssa v0.76.2 `manager_delete.go`), so "add first, then remove" is not safe either. This PR sets `prune: false` on the nine Kustomizations that hand objects over: infrastructure, infrastructure-crds, home-assistant, authentik, immich, matrix, paperless, trmnl, woodpecker. They then drop the moved objects from their inventory without deleting them, and the new owners adopt them. Part 10 turns pruning back on. **Rollout:** merge, check that the nine Kustomizations reconciled this revision (`flux get ks`), then go on with part 1. Until part 10, objects deleted from these nine Kustomizations stay in the cluster; the stack itself deletes none. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-10-17 20:23:42 +00:00

fix(flux): no pruning in the Kustomizations that hand objects to new owners

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

review-bot reviewed: comment

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

04b3f81e00

The restore-test stack moves objects between Kustomizations:
- bird and netbird-service-sync to infrastructure-inhouse;
- crowdsec, external-dns-unifi, netbird-ingress, velero and the Velero
  Schedules, plus their ExternalSecrets, to their own Kustomizations;
- shelly-manager and the mDNS relay to home-assistant-iot;
- the CNPG ObjectStores to cnpg-object-stores.

Flux's garbage collection deletes an object dropped from a Kustomization's
source if its live owner labels (kustomize.toolkit.fluxcd.io/name and
/namespace) still name that Kustomization. Those labels belong to whichever
Kustomization applied the object last. Two phases (add to the new owner,
then remove from the old one) therefore do not guarantee anything: if the
old owner applied last before phase 2, it prunes the object
(kustomize-controller v1.9.6 deleteObjects, fluxcd/pkg/ssa v0.76.2
manager_delete.go).

With prune: false the giving Kustomizations drop the moved objects from
their inventory without deleting them, and the new owners adopt them. This
covers infrastructure, infrastructure-crds, home-assistant, authentik,
immich, matrix, paperless, trmnl and woodpecker. The last PR of the stack
switches prune back on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review-bot reviewed

2026-10-17 20:24:26 +00:00

review-bot left a comment

🤖 Automated review — model claude-sonnet-5-5, commit 04b3f81e0041369f67eab8ec0202e32a3b02b317.

Automated review by the review-bot: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review.

Summary

This PR sets prune: false on the nine Flux Kustomizations that hand objects to new owners: infrastructure, infrastructure-crds, home-assistant, authentik, immich, matrix, paperless, trmnl and woodpecker. It is a one-line change in each of eight files, and infrastructure.yaml holds two of the Kustomizations. The change is mergeable and matches the PR's stated purpose. I found no blocking defects.

⚪ Unverified

Flux behaviour. The PR's central claim is that with prune: false a Kustomization drops moved objects from its inventory without deleting them. It also claims the new owner then adopts them. The claim rests on kustomize-controller v1.9.6 and fluxcd/pkg/ssa v0.76.2 internals, which I can't read from this repo, so I did not verify it. The repo's own history shows the same pattern in use: per-object prune: disabled annotations carried the seed→apps moves (e.g. commits 6900271f, 8a63be85, ab658982). That supports the approach, but it doesn't prove the Kustomization-level behaviour. Check the first handover on the live cluster, for example by running flux get ks and looking at .status.inventory.
Stack ordering. The body says each part is based on the previous one, but #1297 (part 1) has base master, not split/00-prune-handover. Parts 4–8 (#1300, #1301, #1302 and #1304) drop objects from these Kustomizations, and nothing in git forces #1307 to merge first. The PR also says it replaces #1297–#1305, yet those PRs are still listed as open. If any of them merges before this one, Flux's garbage collection can delete the moved objects. For #1304, that includes the ObjectStores and the CNPG-related objects. Please make sure #1307 merges and reconciles first, and close or retarget the superseded PRs.

🟡 Suggestions

kubernetes/clusters/homelab/*.yaml (the nine prune: false lines): none carries a comment saying the setting is temporary. The only record of "turn pruning back on in part 10" is this PR's description. If part 10 slips or is dropped, these nine Kustomizations, including infrastructure with its hundreds of objects, would silently stop pruning. A short comment at each line, e.g. # temporary: restore-test handover, re-enable in part 10, or a tracking issue would stop that. The PR's own diff hunks show no such comment.
The infrastructure-crds and infrastructure entries in infrastructure.yaml:14 and infrastructure.yaml:73 are both affected. Other Kustomizations in that file (infrastructure-cnpg-barman at line 101, infrastructure-ceph-cluster at line 123) stay prune: true. From the file lists of #1300, #1301, #1302 and #1304, none of those two sources objects, so leaving them as they are looks right.

Tests

There are no tests, and none are expected for a manifest-only change. The rollout step in the description (flux get ks to confirm all nine reconciled this revision before part 1) is the right check. Part 1 should wait until it passes.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `claude-sonnet-5-5`, commit `04b3f81e0041369f67eab8ec0202e32a3b02b317`. > Automated review by the `review-bot`: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review. --- ## Summary This PR sets `prune: false` on the nine Flux Kustomizations that hand objects to new owners: infrastructure, infrastructure-crds, home-assistant, authentik, immich, matrix, paperless, trmnl and woodpecker. It is a one-line change in each of eight files, and `infrastructure.yaml` holds two of the Kustomizations. The change is mergeable and matches the PR's stated purpose. I found no blocking defects. ## ⚪ Unverified - **Flux behaviour.** The PR's central claim is that with `prune: false` a Kustomization drops moved objects from its inventory without deleting them. It also claims the new owner then adopts them. The claim rests on kustomize-controller v1.9.6 and fluxcd/pkg/ssa v0.76.2 internals, which I can't read from this repo, so I did not verify it. The repo's own history shows the same pattern in use: per-object `prune: disabled` annotations carried the seed→apps moves (e.g. commits 6900271f, 8a63be85, ab658982). That supports the approach, but it doesn't prove the Kustomization-level behaviour. Check the first handover on the live cluster, for example by running `flux get ks` and looking at `.status.inventory`. - **Stack ordering.** The body says each part is based on the previous one, but #1297 (part 1) has base `master`, not `split/00-prune-handover`. Parts 4–8 (#1300, #1301, #1302 and #1304) drop objects from these Kustomizations, and nothing in git forces #1307 to merge first. The PR also says it replaces #1297–#1305, yet those PRs are still listed as open. If any of them merges before this one, Flux's garbage collection can delete the moved objects. For #1304, that includes the ObjectStores and the CNPG-related objects. Please make sure #1307 merges and reconciles first, and close or retarget the superseded PRs. ## 🟡 Suggestions - `kubernetes/clusters/homelab/*.yaml` (the nine `prune: false` lines): none carries a comment saying the setting is temporary. The only record of "turn pruning back on in part 10" is this PR's description. If part 10 slips or is dropped, these nine Kustomizations, including `infrastructure` with its hundreds of objects, would silently stop pruning. A short comment at each line, e.g. `# temporary: restore-test handover, re-enable in part 10`, or a tracking issue would stop that. The PR's own `diff` hunks show no such comment. - The `infrastructure-crds` and `infrastructure` entries in `infrastructure.yaml:14` and `infrastructure.yaml:73` are both affected. Other Kustomizations in that file (`infrastructure-cnpg-barman` at line 101, `infrastructure-ceph-cluster` at line 123) stay `prune: true`. From the file lists of #1300, #1301, #1302 and #1304, none of those two sources objects, so leaving them as they are looks right. ## Tests There are no tests, and none are expected for a manifest-only change. The rollout step in the description (`flux get ks` to confirm all nine reconciled this revision before part 1) is the right check. Part 1 should wait until it passes. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

claude-bot referenced this pull request

2026-10-17 20:25:06 +00:00

Restore test 1/9: small standalone fixes (ceph-csi-drivers, Gitea PVC, mqtt-account-controller) #1297

claude-bot referenced this pull request

2026-10-17 20:25:39 +00:00

Restore test 2/9: site facts in the Talos site patches #1298

claude-bot referenced this pull request

2026-10-17 20:25:41 +00:00

Restore test 3/9: Flux dependency graph and health #1299

claude-bot referenced this pull request

2026-10-17 20:25:42 +00:00

Restore test 4/9: infrastructure-inhouse waits for Gitea #1300