Skip to content

feat: Record an attachment's egress request on its node - #26

Draft
scotwells wants to merge 1 commit into
mainfrom
feat/egress-shard-claim
Draft

scotwells wants to merge 1 commit into
mainfrom
feat/egress-shard-claim

Conversation

@scotwells

Copy link
Copy Markdown
Collaborator

Summary

Turning internet egress on or off for a network today only takes effect on a workload when it is attached again, because the node learns the declaration once, at attach time.

This adds an EgressShardClaim: one per attachment, written by the cell controller while the attachment's network declares egress and deleted when it stops. A node's installer lists the claims naming it and keeps each VRF's egress route in step, so a live toggle converges without touching the workload.

The claim also records which shard the attachment leaves through, and says why it is not bound when it isn't.

Test plan

  • A claim is refused without its attachment, VPC, node or a family, and refuses a family no shard translates
  • A claim's spec cannot be edited once written, while its status stays writable
  • Generated CRD, deepcopy and API reference match the types

Related to datum-cloud/network-services-operator#475

🤖 Generated with Claude Code

The cell controller creates one claim per attachment whose network
declares internet egress, once the attachment has reported its node,
and deletes it when the declaration is withdrawn. The node's installer
lists the claims naming it on every sweep and keeps each VRF's egress
route in step, so egress can be turned on or off for a running
workload without re-attaching it.

The claim also records the binding: status names the shard on the
node, and the Ready condition says why a claim is not bound.

Key changes:
- Spec carries the attachment, its VPC, the node and the families, and
  is immutable, so a moved attachment gets a new claim
- A node label restates the node so an installer can list its claims
  server-side, and a shard label lists a shard's consumers
- Chainsaw test covers the required fields, the family enum, spec
  immutability and a writable status

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.

1 participant