fix(infrastructure): LAPI ServersTransport behind the Traefik CRDs (phase 2/2, remove) #809

Merged
k.renner merged 1 commits from lapi-transport-phase-2 into master 2026-09-07 06:09:32 +00:00
Member

LAPI ServersTransport move — phase 2 of 2 (remove the original)

Follow-up to #802, which added the ServersTransport under post-crds/. infrastructure-crds has applied it (Kustomization Ready), so the copy in crowdsec/lapi-ingress.yaml goes; the Ingress stays there (core kind, no CRD dependency).

What Flux will do on merge

Both Kustomizations currently own the object and the kustomize.toolkit.fluxcd.io/name label flips to whichever applied last (it reads infrastructure right now). On this revision infrastructure reconciles first (infrastructure-crds depends on it) and prunes the object from its inventory; Flux skips prune when the label names another Kustomization, otherwise it deletes and infrastructure-crds recreates it seconds later. Worst case is therefore a seconds-long gap in the public LAPI backend transport — only the external proxy bouncers poll through that Ingress; the in-cluster Traefik middleware talks to the LAPI service directly and is unaffected.

After this, a cold rebuild's infrastructure apply set contains no traefik.io consumer any more (verified on the Hetzner rehearsal branch, where this exact end state let infrastructure apply and 23 HelmReleases come up).

🤖 Generated with Claude Code

## LAPI ServersTransport move — phase 2 of 2 (remove the original) Follow-up to #802, which added the ServersTransport under `post-crds/`. `infrastructure-crds` has applied it (Kustomization Ready), so the copy in `crowdsec/lapi-ingress.yaml` goes; the Ingress stays there (core kind, no CRD dependency). ### What Flux will do on merge Both Kustomizations currently own the object and the `kustomize.toolkit.fluxcd.io/name` label flips to whichever applied last (it reads `infrastructure` right now). On this revision `infrastructure` reconciles first (`infrastructure-crds` depends on it) and prunes the object from its inventory; Flux skips prune when the label names another Kustomization, otherwise it deletes and `infrastructure-crds` recreates it seconds later. Worst case is therefore a seconds-long gap in the *public* LAPI backend transport — only the external proxy bouncers poll through that Ingress; the in-cluster Traefik middleware talks to the LAPI service directly and is unaffected. After this, a cold rebuild's `infrastructure` apply set contains no traefik.io consumer any more (verified on the Hetzner rehearsal branch, where this exact end state let `infrastructure` apply and 23 HelmReleases come up). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-09-07 05:48:35 +00:00
fix(infrastructure): LAPI ServersTransport behind the Traefik CRDs (phase 2: remove)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
5d52e42887
Phase 1 (#802) put the ServersTransport under post-crds and
infrastructure-crds has applied it. The copy in crowdsec/lapi-ingress.yaml
goes; the Ingress stays (core kind). With it, the infrastructure apply set
holds no traefik.io consumer any more, which is what a cold rebuild needs.

Prune: infrastructure reconciles first and skips the object if the last
applier label names infrastructure-crds; otherwise it deletes and
infrastructure-crds recreates it seconds later. Only the public LAPI
ingress used by the external bouncers is behind that transport.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
review-bot left a comment
Member

🤖 Automated review — model CLI default (complexity: complex), commit 5d52e42887937431a7f323b93fe890af47a19801.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.


Summary

Phase 2 of a two-step move of the crowdsec-lapi ServersTransport from crowdsec/lapi-ingress.yaml into post-crds/crowdsec-lapi-serverstransport.yaml: this PR deletes the now-duplicate copy embedded in lapi-ingress.yaml and drops the phase-1 "keep both until applied once" comment from post-crds/kustomization.yaml. Verified against the checkout: the post-crds copy already exists and is wired into post-crds/kustomization.yaml's resources, no other file references the deleted copy, the surviving lapi-ingress.yaml is a single clean YAML document (no stray --- left behind), and the infrastructure-crds → infrastructure dependsOn in kubernetes/clusters/homelab/infrastructure.yaml matches the reconcile-order reasoning given in the PR description. No blocking issues found.

🟡 Suggestions

None beyond what's already noted below as a nit.

🟢 Nits

  • kubernetes/infrastructure/crowdsec/lapi-ingress.yaml:9-10 — the diff replaces the comment-block divider ---- (a line of four dashes, not a YAML document separator) with #, merging what were two visually distinct comment paragraphs into one contiguous block. Purely cosmetic; the resulting comment still reads fine.

Tests

This is a GitOps manifest move with no application logic — there's no test suite to extend, consistent with the rest of kubernetes/infrastructure/. The safety property that matters (no two Kustomizations owning the same object at apply time) was validated out-of-band per the PR body (Hetzner rehearsal branch cold rebuild). Nothing in the checkout contradicts that account, though I could not independently confirm the rehearsal-branch run from this repo checkout alone.

Recommendation

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

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `5d52e42887937431a7f323b93fe890af47a19801`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Phase 2 of a two-step move of the `crowdsec-lapi` `ServersTransport` from `crowdsec/lapi-ingress.yaml` into `post-crds/crowdsec-lapi-serverstransport.yaml`: this PR deletes the now-duplicate copy embedded in `lapi-ingress.yaml` and drops the phase-1 "keep both until applied once" comment from `post-crds/kustomization.yaml`. Verified against the checkout: the `post-crds` copy already exists and is wired into `post-crds/kustomization.yaml`'s `resources`, no other file references the deleted copy, the surviving `lapi-ingress.yaml` is a single clean YAML document (no stray `---` left behind), and the `infrastructure-crds` → `infrastructure` `dependsOn` in `kubernetes/clusters/homelab/infrastructure.yaml` matches the reconcile-order reasoning given in the PR description. No blocking issues found. ## 🟡 Suggestions None beyond what's already noted below as a nit. ## 🟢 Nits - `kubernetes/infrastructure/crowdsec/lapi-ingress.yaml:9-10` — the diff replaces the comment-block divider `----` (a line of four dashes, not a YAML document separator) with `#`, merging what were two visually distinct comment paragraphs into one contiguous block. Purely cosmetic; the resulting comment still reads fine. ## Tests This is a GitOps manifest move with no application logic — there's no test suite to extend, consistent with the rest of `kubernetes/infrastructure/`. The safety property that matters (no two Kustomizations owning the same object at apply time) was validated out-of-band per the PR body (Hetzner rehearsal branch cold rebuild). Nothing in the checkout contradicts that account, though I could not independently confirm the rehearsal-branch run from this repo checkout alone. ## Recommendation Looks reasonable — no blocking issues; comments above are optional. <!-- pr-review:sha=5d52e42887937431a7f323b93fe890af47a19801 -->
k.renner merged commit c7fd3e208a into master 2026-09-07 06:09:32 +00:00
Sign in to join this conversation.