Skip to content

Report a Subnet as programmed only when its cells carry the range - #640

Merged
scotwells merged 1 commit into
mainfrom
feat/subnet-programmed-from-cell
Oct 14, 2026
Merged

scotwells merged 1 commit into
mainfrom
feat/subnet-programmed-from-cell

Conversation

@scotwells

Copy link
Copy Markdown
Contributor

Why

Every subnet in staging has shown NotProgrammed since the day it was created, and datumctl network list names it as the root cause on every network, while the workloads in those networks are serving traffic. Nothing in the Datum-native networking path ever wrote the Subnet's Programmed condition, so Ready could never turn true. The October 9 UI change papered over the symptom; this closes the gap with a real signal.

What changes for a customer

  • A network's address range in a location reads Ready once every cell serving that location actually routes it, and goes back to not ready if a cell stops.
  • Until the cells have reported, the range reads Pending ("has not yet reported") instead of a false NotProgrammed verdict.
  • A range a cell was built without now surfaces as NotProgrammed, which today is a silent bug.

How

The cell's data plane already builds a VPC per network presence carrying the subnet's range, and marks it ready once the fabric identity lands. That is the signal.

  1. The cell writes Programmed on its propagated Subnet copy, against the project's generation (datum-cloud/cloud PR, linked below).
  2. Karmada AND-aggregates the cells' reports onto the hub copy (datum-cloud/infra PR, linked below).
  3. This PR: the subnet controller reads the hub copy's aggregated condition, takes it only for the current upstream generation, derives Programmed and Ready, and requeues when the hub copy changes. The replicator now stamps the upstream generation on the Subnet copy so step 1 can report against it.

Same shape as the TrafficProtectionPolicy Programmed path landed last week.

Rollout

All three PRs are independently safe. With only this one deployed, subnets read Pending instead of NotProgrammed until the cells and the interpreter ship.

Verified

  • Unit and envtest coverage for the hub-copy derivation, generation guard, hub-to-project requeue mapping, and Ready following the cells both ways.
  • make manifests generate produces no drift; lint clean.

Related: datum-cloud/cloud and datum-cloud/infra PRs (links in first comment).

🤖 Generated with Claude Code

Every subnet in staging has read NotProgrammed since it was created, and
datumctl names it as the root cause on every network, while workloads in
those networks serve traffic. Ready gated on Programmed, and nothing in
the Datum-native path ever wrote Programmed: the replicator mirrors the
subnet to the hub with status sync off, and the subnet controller only
ever read the condition back.

The cells have had the real answer all along. Each cell's data plane
builds a VPC for the network's presence in its location, carrying the
subnet's range, and the VPC is ready once the fabric identity lands.
Programmed now reports that: the cell writes it on its copy against the
project's generation, Karmada aggregates the cells' reports onto the hub
copy, and the subnet controller derives Programmed and Ready from there.

Key changes:
- Read the hub copy's aggregated Programmed condition in the subnet
  controller, accepted only for the current upstream generation, and
  requeue the project subnet when the hub copy changes
- Stamp the upstream generation on the replicated Subnet so a cell can
  report against the generation the project knows
- Treat a subnet with no report yet as Pending rather than NotProgrammed,
  and say so in the reason catalog without naming cells
- Drop the predicate that stopped reconciling a Ready subnet, since a
  range the cells stop carrying is no longer ready

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@scotwells

Copy link
Copy Markdown
Contributor Author

Related: cell report datum-cloud/cloud#32, hub aggregation https://github.com/datum-cloud/infra/pull/6988. All three are independently safe to ship; the signal is live once all three are deployed.

@scotwells
scotwells merged commit 8523429 into main Oct 14, 2026
17 of 19 checks passed
@scotwells
scotwells deleted the feat/subnet-programmed-from-cell branch October 14, 2026 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants