feat: add --milo-kubeconfig and --leader-election-namespace flags#13
Merged
Conversation
When the controller is deployed alongside Milo's aggregated API server, the Vendor and Subprocessor CRDs live in Milo while the controller pod runs in the local `compliance-system` namespace on the host cluster. Forcing every client-go call at Milo (e.g. via `KUBECONFIG`) breaks leader election because controller-runtime's default lease namespace detection picks up the host pod's `compliance-system` namespace, which does not exist on Milo, and the manager spins forever logging "namespaces \"compliance-system\" not found". Add two flags so callers can place the manager and its lease anywhere they need: - `--milo-kubeconfig`: path to a kubeconfig for the Milo API server. When set, the manager's REST config is built from it and reconcilers watch Milo CRs. Empty falls back to the in-cluster config for local development. - `--leader-election-namespace`: explicit namespace for the leader-election Lease. Defaults to controller-runtime's auto-detection. When the manager is pointed at Milo, callers should set this to a namespace that exists there (e.g. `milo-system`); the lease is then coordinated by the same control plane that owns the resources, which matters once we run multiple replicas across host clusters. Existing local-development setups (no flags) are unaffected.
ada7a3d to
3820a9c
Compare
scotwells
approved these changes
May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--milo-kubeconfigflag mirroring the fraud manager. When set, the controller's REST config is loaded from that kubeconfig so reconcilers watch Vendor/Subprocessor on Milo's aggregated API server.--leader-election-namespaceflag so callers can place the leader-electionLeasein a namespace that actually exists on whichever cluster the manager is pointed at. Without this, the live staging deployment hadKUBECONFIGoverridden to point at Milo and the manager attempted to write the lease into acompliance-systemnamespace that does not exist on Milo, looping forever on `namespaces "compliance-system" not found` and never starting reconcilers (so no Subprocessor was ever derived from the Active Vendor).ctrl.GetConfigOrDie()still picks up the in-cluster or default kubeconfig and lease namespace detection still falls back to controller-runtime's defaults.This keeps both the reconcilers and the lease on the same control plane (Milo, when configured), which is what we want once multiple replicas run across host clusters: the lease is coordinated by the same API server that owns the resources.
Test plan
go build ./...andgo vet ./...pass.KUBECONFIGoverride and adds--milo-kubeconfig=/etc/kubernetes/project-discovery/auth/discovery-kubeconfig.yaml --leader-election-namespace=milo-system, the controller logs `using milo kubeconfig …` followed by `starting manager` and starts reconciling Vendors.