Repository navigation
Open
Labels
area/coreCore config, validation, and runtimeCore config, validation, and runtimebugInvestigate as a BugInvestigate as a Bugpriority/mediumMedium-priority workMedium-priority worktriage/accepted
Milestone
Description
Problem
Under Local membership two status results misreport the state of a site that has no peers and no endpoints yet. Observed on main (c225465) with the operator installed in its defaults (Swim fallback, its own record creation on) and a complete GridNetwork (gridId, Local, poll, SPIFFE, identity and CA refs) applied after it started.
- The site's own GridSite stays Pending with reason
AwaitingDiscoveryand the message "waiting for SWIM discovery to advance to Discovered". Nothing is discovered under Local. What the site is waiting for is its gateway and signals endpoints. The reason comes from theGridSitePhase::Pendingfallback insite_phase_under(crates/operator/src/controller/grid_site.rs). - With no peer GridSite declared,
PeerSignalsReachable,PeerCatalogsAccepted,PeerPollsComplete,PeerMembershipandPeerTimeValidon the GridNetwork all reportTrue. No peer was polled, so the status reads as a healthy mesh that does not exist.
The GridNetwork itself is correct: Pending with GridIdUnset before the network is delivered, then one restart into Local, Active, and Accepted, ResolvedRefs, IdentityValid and Available True.
Scope
- Under Local, a declared GridSite that cannot leave Pending names the missing endpoint:
GatewayAddressMissingwhenspec.gatewayEndpoint.addressis unset, andSignalsAddressMissingwhen a gateway address is set but no dialable signals address can be derived.AwaitingDiscoverystays for Swim only. - With zero declared peers, each peer condition reports
Unknownwith reasonNoDeclaredPeers. It must not beTrue, and must not beFalse, since aFalsepeer condition setsDegradedand a single site waiting for its first peer is not degraded. - Peer conditions leave
Unknownonce a peer GridSite is declared and polled.
Acceptance criteria
- A Local site's own GridSite without endpoints reports
GatewayAddressMissing; with a non-dialable gateway address and nosignalsEndpointit reportsSignalsAddressMissing; with both declared it moves to Connecting withEndpointsDeclaredas today. - A Swim site without discovery still reports
AwaitingDiscovery. - A Local GridNetwork with no declared peers reports the five peer conditions
Unknown/NoDeclaredPeers, and is still Active andAvailable, notDegraded. - Declaring a reachable peer moves the peer conditions to their existing
Truereasons. - A kind e2e leg covers a delivered network landing on a running operator and asserts the status before delivery, after delivery, and after a peer is declared.
- The GridSite reason table and the GridNetwork peer condition tables in
docs/architecture/crds.mdlist the new reasons.
Metadata
Metadata
Assignees
Labels
area/coreCore config, validation, and runtimeCore config, validation, and runtimebugInvestigate as a BugInvestigate as a Bugpriority/mediumMedium-priority workMedium-priority worktriage/accepted
Activity
hexfusion commentedon Oct 30, 2026
Both results reproduce on main 79d3490 on a real cluster: a single-node OpenShift site installed through ACM, with Local membership and poll signals. It has no peers yet, and the provider gateway isn't deployed.
site-ehas neitherspec.gatewayEndpointnorspec.signalsEndpoint. It stays Pending withAvailable=False AwaitingDiscoveryand the message "waiting for SWIM discovery to advance to Discovered". Under the proposed scope it would reportGatewayAddressMissing.PeerPollsComplete,PeerSignalsReachable,PeerCatalogsAccepted,PeerTimeValidandPeerMembershipall True, andAvailable=True.On ACM there is a second consequence. The
grid-local-endpointspolicy that fills in the gateway address waits for the provider gateway's Route. Until that Route exists, the misleading SWIM message is the only status a user sees.