Jean-Gabriel Gill-Couture
cc41f190d2
Some checks failed
Run Check Script / check (pull_request) Failing after 59s
The k3d smoke-test surfaced that the operator chart baked
`fleet-system` into every namespaced manifest (Deployment,
ServiceAccount, Secret) and into the ClusterRoleBinding subject.
Installing into any other namespace failed with helm
release-namespace mismatch.
Fixed by making the chart genuinely namespace-neutral:
- Removed `namespace` from `ChartOptions` entirely.
- `service_account()` and `operator_deployment(opts)` no longer
set `metadata.namespace`; helm assigns the release namespace at
install time, and the direct-apply path injects the namespace
through `K8sResourceScore::single(.., Some(ns))`.
- `operator_secret(opts)` likewise drops `metadata.namespace`; the
Secret is applied with an explicit namespace by its caller.
- `cluster_role_binding(subject_namespace)` keeps a namespace
argument because the CRB subject must point at a concrete
namespace; the chart path passes the literal helm template
`{{ .Release.Namespace }}` so helm substitutes the release
namespace at install time. The direct-apply path passes the
real namespace string.
- `FleetOperatorScore::new()` defaults its own `namespace` field
(no longer sourced from `ChartOptions::default()`); the chart
itself carries no namespace default at all.
Verified on k3d by installing the released chart into a
deliberately non-default namespace (`my-fleet`): all resources
land in `my-fleet`, ClusterRoleBinding subject resolves to
`my-fleet`, operator pod runs.
Also adds `ROADMAP/fleet_platform/dashboard_ingress.md` capturing
the three-step dependency chain (build with web-frontend feature →
implement real FleetService → add Service + Ingress to chart) that
the k3d test surfaced when looking for the dashboard. Unnumbered
file per project convention; numbered ones are versioned
milestones.