Repository navigation
feat(cli): Kates Backend is a deploy choice, --with-kates - #579
Conversation
The Kates Backend status row selected pods by app.kubernetes.io/instance=kates, which the chart's embedded PostgreSQL pod also carries, so "2/2 pods" counted the API and its database together and the database had no row of its own. Each is now checked by name: the kates Deployment and the kates-postgresql StatefulSet. The wizard's component page names both, with Kafka, as always deployed.
![graphify-labs[bot]](https://avatars.githubusercontent.com/in/4356270?s=60&v=4){kind=small}
There was a problem hiding this comment.
Graphify reviewed this change.
Code graph out of date: Health delta baseline: last indexed commit 0a08117, 7 commit(s) behind this PR's base. Impact and hotspot numbers below may be wrong.
Worth a look — the grounded gate found no coupling regressions or blocking issues, but 1 advisory finding(s) below merit a look before merge.
Not checked: tests were not run; no formal proof of the changed code.
Graphify review — findings
Fixes the Kates status rows so the backend is checked as the kates deployment and its embedded PostgreSQL as the kates-postgresql statefulset, instead of a pod label selector that matched both pods. statusComponents now emits a separate "Kates Database" row, and both rows reuse the kates component key, so anything that looks up status or Helm state by that key sees two entries. The component picker in runComponentForm also gets an "Always deployed" note listing the Kates backend, its database and the Kafka cluster.
Worth a look
- Backend and Database status rows share the same component key "kates" —
cli/cmd/deploy_status.go:172· Escalate · medium- NOT verified (no proof, no reproducing execution) — needs human review
Analysis details — impact, health, verification
Impact & health
Graphify review
Impact — 152 functions depend on the 58 functions this change touches.
Health — this change adds coupling hotspots:
- worse:
runDeploy()— 20 callers, 27 callees - new:
runDeployAndReport()— 1 callers, 6 callees
Verification — 152 functions in the blast radius were not formally verified this run (proofs are advisory here).
Health delta baseline: last indexed commit 0a08117, 7 commit(s) behind this PR's base.
Gate & verification
graphify gate
PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.
Advisory (not blocking):
- verification_scope: 126 function(s) in the blast radius were not formally verified this run
· 2 more finding(s) on lines outside this diff (see the check run).
The wizard lists Kates Backend beside the other components, ticked by default, and --with-kates=false deploys the stack without it. Kates installs with its embedded PostgreSQL as before; left out, its release, namespace, API key sync, compliance Role check and admin-less grants are skipped. deploy status shows one Kates Backend row, checked as the kates Deployment, and no longer a separate database row.
bmscomp
changed the title
A deploy into an existing namespace failed for an account without patch on
namespaces: Helm 4 server-side applies the Namespace for --create-namespace
even when it exists ("cannot patch resource namespaces", kafka-cluster).
Deploy creates its namespaces itself before Helm runs and keeps one that is
already there, so --create-namespace now leaves every deploy's helm calls,
not only admin-less ones. A namespace the account may not read is used as
it is, and one made meanwhile by a parallel component is not an error.
Why
The deploy wizard never listed Kates. The backend was always installed, with no way to deploy the stack without it.
kates deploy statuschecked "Kates Backend" byapp.kubernetes.io/instance=kates, which the chart's embedded PostgreSQL pod also carries, so "2/2 pods" counted the API and its database together.What
--with-kates(defaulttrue).--with-kates=falsedeploys everything else.katesrelease, its namespace, the API-key sync into the active context, the compliance-Role check, and the admin-less ServiceMonitor grants in the app namespace.katesDeployment, so the database pod no longer counts toward it.--upgrade kateson a deploy without Kates names--with-katesin its refusal.Existing namespaces
A deploy into a namespace that already existed failed for an account without
patchon namespaces:Helm 4 server-side applies the Namespace for
--create-namespaceeven when it exists. Deploy already creates its namespaces itself before Helm runs and keeps one that is there, so--create-namespaceis now stripped from every deploy's Helm calls (admin-less already did this). Also:cannot get resource "namespaces") is used as it is. The install says so if it is truly missing.AlreadyExists) is used, not reported as an error.Checked
go test -p 1 ./... -race,go vet,check-cli-compat.sh,check-cli-style.sh, andgolangci-lint --new-from-revwith 0 issues.TestDeployCommand_WithoutKates, deploys with Kates off: nokatesrelease is installed, and Kafka still is. Forcing the component on makes the test fail.TestDeployNeverPassesCreateNamespaceToHelm(fails on 3 Helm calls with the old behaviour),TestEnsureDeployNamespaceUnreadableIsUsedAsItIs,TestEnsureDeployNamespaceCreatedMeanwhileIsUsed.helm template kates charts/katesrendersDeployment/kates.Deliberately not done
kates portsstill tries to forward the Kates API when it isn't installed.deploy statusshows its row as "missing / Not deployed", like any other component left out.