Put fider under Flux, alongside ArgoCD

[jacksonloper]

Puts one app under Flux, next to the ArgoCD config it would eventually replace.

Merging this changes nothing

ArgoCD cannot see flux/:

• the applications ApplicationSet generator globs applications/**/config.json
• the bootstrap-cluster Application syncs path: applications

Both are scoped to applications/, so this directory is invisible to it. Nothing activates until someone runs flux bootstrap. This PR also does not remove applications/fider/config.json or applications/fider-db/config.json — that is the cutover, and it is deliberately a separate change.

Why fider

It is served publicly at feedback.prod.equal.vote (returns 200) but is not reachable from the product — grep -rn 'fider\|feedback\.prod' packages/frontend/src packages/backend/src in the bettervoting repo returns nothing. It is the one app where a migration mistake costs nothing.

Which is an argument for using it to rehearse the hard path rather than dodge it. It happens to exercise three of the four blockers in bvflux/MIGRATION.md:

Blocker	Why fider hits it	Also needed for
Helm adoption	real PVC + CNPG cluster to adopt in place	postgresql, keycloak
SSA field handover	ArgoCD owns fields as argocd-controller	every app

The third blocker — the devopscoop chart — is gone from this path entirely. See below.

What's in it

flux/clusters/equalvote/{sources,apps}.yaml   two Kustomizations; apps dependsOn sources
flux/sources/helmrepositories.yaml            cloudnative-pg only
flux/base/app/                                the devopscoop wrapper, as manifests we own
flux/apps/fider/                              overlay + fider-db HelmRelease
flux/README.md                                cutover runbook, prerequisites, rollback

No third-party app chart

flux/base/app replaces devopscoop/charts/app — the same four objects (ServiceAccount, Service, Deployment, Ingress) as a kustomize base, with flux/apps/fider as the overlay. Kustomize-native is the idiomatic shape under Flux anyway, and it makes this path self-contained.

Verified with kubectl kustomize flux/apps/fider against the live cluster (re-run 2026-09-10, after fider re-synced under chart 0.11.1). The Deployment selector, container name, image, serviceAccountName, env, resources and ports; the Service selector and ports; and the entire Ingress spec all render identical to what is running.

Two design notes:

• The label app.kubernetes.io/name: app is kept on purpose. It's half of the live Deployment's selector, and selectors are immutable — dropping it would force a delete/recreate. The overlay adds app.kubernetes.io/instance: fider through labels with includeSelectors: true, reproducing {app.kubernetes.io/name: app, app.kubernetes.io/instance: fider} exactly.
• Adoption causes one pod rollout. The rendered template drops three Helm bookkeeping labels (helm.sh/chart, app.kubernetes.io/managed-by, app.kubernetes.io/version), which changes the pod-template hash. Harmless for fider; flagged so it's expected rather than debugged.

fider-db stays a HelmRelease on the upstream CloudNativePG chart — a real upstream rather than an in-house wrapper, and keeping it preserves the Helm-adoption rehearsal postgresql and keycloak will need.

Chart revisions match config.json exactly (cluster 0.8.1), and the HelmRelease spec.values parse identically to applications/fider/values.yaml and applications/fider-db/values.yaml — asserted in a YAML round-trip while authoring. So adoption should produce a no-op helm upgrade.

The values comments came across verbatim, including the lingua-go measurements (~356MB steady state, the 200Mi OOMKill that read as a hung submit) and the single-instance enablePDB: false note about drains stalling AKS upgrades. Those are incident knowledge and shouldn't be lost in a translation.

⚠️ Removing any app from the ApplicationSet currently destroys its data

This is true today, for every app, and has nothing to do with Flux:

ApplicationSet syncPolicy:      (none)   <- no preserveResourcesOnDeletion
fider / fider-db finalizers:    resources-finalizer.argocd.argoproj.io
PV pvc-df9a66c8 (Bound, live):  Delete
PV pvc-00a3f621 (Released):     Retain   <- the OLD volume from the August incident

Deleting a config.json deletes the Application, the finalizer cascades, ArgoCD deletes the workloads including the CNPG Cluster and PVC, and the PV reclaims. The Retain applied after the August CNPG wedge protects the previous volume, not the one in use since the 08-29 rebuild.

Worth fixing on its own merits, ahead of any migration — preserveResourcesOnDeletion: true on the ApplicationSet covers every app at once. starvote/postgresql is the one that matters.

Deliberately not done

• Secrets stay with ArgoCD. fider and fider-db-creds come from the standalone bootstrap-secrets app, which is outside the ApplicationSet and unaffected. Moving them to Flux SOPS needs Azure Key Vault workload identity for kustomize-controller — not doable in git alone.
• cnpg-operator stays with ArgoCD. Flux can't dependsOn an ArgoCD Application. The operator is already running; documented gap, not an ordering bug.
• No other app is touched.

Not verified

The kustomize overlay is rendered and diffed against the live cluster (kubectl kustomize has kustomize built in), re-verified 2026-09-10. What is not verified: the Flux Kustomization/HelmRelease/HelmRepository resources themselves, which need a running Flux to validate — flux build kustomization apps --path ./flux/apps once bootstrapped.

Nor is the cnpg cluster 0.7.0 -> 0.8.1 values schema checked by anything here. The values are byte-identical to applications/fider-db/values.yaml, which ArgoCD renders successfully at 0.8.1 today, so this is low risk — but it is inference, not a render.

On devopscoop

I asserted twice while drafting this that registry.gitlab.com/devopscoop/charts was a private blocker needing credentials. It isn't — a token from gitlab.com/jwt/auth with no credentials lists every tag and pulls both 0.11.0 and 0.8.2. So access was never the issue; the chart is a generic in-house wrapper shared by four apps, and nothing about fider required it.

The remaining exposure is continuity: be16440 records the chart has already been relocated once, "migrated from the now-deprecated dedevsecops org", and version drift is live (fider 0.11.0, the other three 0.8.2). flux/base/app removes it from the Flux path. star-server, alaska-rcv and discord-bot still use it under ArgoCD and are untouched — but the base is written to be reusable, so a second overlay supplying its own name, image, env and ingress should be most of what another app needs.

Open question for review

Should this live here, or in jacksonloper/bvflux? Argument for here: .sops.yaml and secrets/ already exist, one deploy key, and each app handover becomes a single atomic PR that removes config.json and adds Flux manifests together. Argument against: the repo is named argocd. That's a gh repo rename away — GitHub redirects git operations, so the valuesURL in all 14 config.json files keeps working and can be updated at leisure.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MeFy2jujRA8ScQqRAshc1f

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: d2d932e8-75f5-4d5a-9d19-a228346690c7

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[3uzbcqje]

So, yeah, after discussing with Claude, I'm still of the opinion that flux is the end goal, but it's by a pretty paper thin margin. I don't want to install flux and argocd in the same cluster - that will be too resource intensive and potentially dangerous if they both try to manage the same objects. I think we should close this PR, and we should come up with a plan to build a new cluster with flux at some point in the future. If you want to put a deadline on that, we can discuss it at the next meeting.