chore(flux): ungate ten Kustomizations from the Platform claim #755

Merged
binjovi-bot merged 1 commit from chore/decouple-platform-claim-gate into trunk 2026-09-14 16:47:23 +00:00
Owner

What

Sets wait: false on platform-seanfarm-instances and removes its healthChecks block.

This is preparation, not the retirement itself. It has to land before the composition is emptied.

Why it has to come first

./instances now contains exactly one resource: the Platform/seanfarm claim, the last Crossplane object in the cluster. With wait: true, this Kustomization does not report Ready until that claim is Ready -- and ten Kustomizations gate on it:

gitmirrors  olly  ory  ory-portal-bridge  outline
portal  someara-resume  tetragon  zot  platform-seanfarm-instances-post

The next step empties the composition so the XR composes nothing. Whether a composite with zero composed resources still reports Ready=True is not something I was willing to assume with that blast radius behind it. If it reports anything else, all ten stall.

Decoupling first makes that question irrelevant instead of load-bearing.

The gate is already vestigial

Everything the claim composed -- the internal-CA PKI (pki_root, pki_internal, the cnpg-server/cnpg-client/bundle-export roles), the cosign transit backend and the cosign-signer policy -- is declared as plain Flux manifests in infrastructure/openbao-platform as of #750. That Kustomization is itself wait: false.

So the ordering this gate appears to enforce is already not enforced on the path the PKI actually arrives by. It reads like ordering without being ordering.

The healthChecks block was dead configuration

It went with the wait flip, and removing it costs nothing, because Flux ignores spec.healthChecks when wait: true. The comment previously in this file recorded exactly that, as the explanation for how a stale Stack/alice entry naming a retired kind sat there unnoticed:

It was inert only because Flux ignores spec.healthChecks when wait: true -- which is also why nothing noticed.

So this removes dead config, not live behavior.

Risk

Downstream Kustomizations now proceed once the claim is applied rather than Ready. On a cold rebuild that is a real reduction in ordering -- but the same ordering is already absent from openbao-platform, which is where those resources now come from, and make rebuild is deferred and unproven per AGENTS.md. Flagging it rather than burying it.

Reversible: restore wait: true to restore the old coupling.

tests/check.sh exits 0.

https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

## What Sets `wait: false` on `platform-seanfarm-instances` and removes its `healthChecks` block. This is preparation, not the retirement itself. It has to land before the composition is emptied. ## Why it has to come first `./instances` now contains exactly one resource: the `Platform/seanfarm` claim, the last Crossplane object in the cluster. With `wait: true`, this Kustomization does not report Ready until that claim is Ready -- and **ten** Kustomizations gate on it: ``` gitmirrors olly ory ory-portal-bridge outline portal someara-resume tetragon zot platform-seanfarm-instances-post ``` The next step empties the composition so the XR composes nothing. Whether a composite with zero composed resources still reports `Ready=True` is not something I was willing to assume with that blast radius behind it. If it reports anything else, all ten stall. Decoupling first makes that question irrelevant instead of load-bearing. ## The gate is already vestigial Everything the claim composed -- the internal-CA PKI (`pki_root`, `pki_internal`, the `cnpg-server`/`cnpg-client`/`bundle-export` roles), the cosign transit backend and the cosign-signer policy -- is declared as plain Flux manifests in `infrastructure/openbao-platform` as of #750. That Kustomization is itself `wait: false`. So the ordering this gate appears to enforce is already not enforced on the path the PKI actually arrives by. It reads like ordering without being ordering. ## The healthChecks block was dead configuration It went with the `wait` flip, and removing it costs nothing, because **Flux ignores `spec.healthChecks` when `wait: true`**. The comment previously in this file recorded exactly that, as the explanation for how a stale `Stack/alice` entry naming a retired kind sat there unnoticed: > It was inert only because Flux ignores spec.healthChecks when wait: true -- which is also why nothing noticed. So this removes dead config, not live behavior. ## Risk Downstream Kustomizations now proceed once the claim is *applied* rather than *Ready*. On a cold rebuild that is a real reduction in ordering -- but the same ordering is already absent from `openbao-platform`, which is where those resources now come from, and `make rebuild` is deferred and unproven per `AGENTS.md`. Flagging it rather than burying it. Reversible: restore `wait: true` to restore the old coupling. `tests/check.sh` exits 0. https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA
chore(flux): ungate ten Kustomizations from the Platform claim
All checks were successful
binjovi/ci Binjovi completed the frozen plan
ddf5537518
Set wait: false on platform-seanfarm-instances and drop its healthChecks
block. This prepares the Crossplane retirement; it does not perform it.

./instances holds exactly one resource, the Platform/seanfarm claim, which is
the last Crossplane object in the cluster. Under wait: true this Kustomization
stays NotReady until that claim is Ready, and ten Kustomizations depend on it:
gitmirrors, olly, ory, ory-portal-bridge, outline, portal, someara-resume,
tetragon, zot and instances-post.

The next change empties the composition so the XR composes nothing. Whether a
composite with zero composed resources still reports Ready=True is not worth
assuming with ten Kustomizations behind it. Decoupling first makes the question
irrelevant instead of load-bearing.

The gate is already vestigial. Everything the claim composed - the internal-CA
PKI, the cosign transit backend and the cosign-signer policy - is served by
infrastructure/openbao-platform since the previous change, and that
Kustomization is itself wait: false.

The healthChecks block was dead configuration: Flux ignores spec.healthChecks
when wait is true. The comment previously in this file recorded that fact, as
the reason a stale Stack/alice entry naming a retired kind went unnoticed.

Cost: downstream Kustomizations now proceed when the claim is applied rather
than Ready. That ordering is already absent from openbao-platform, which is
where those resources now come from.

Claude-Session: https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA
binjovi-bot deleted branch chore/decouple-platform-claim-gate 2026-09-14 16:47:23 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/seanfarm!755
No description provided.