Add a Prepared condition, and attachmentMode on the claim

[scotwells]

Two additions that let a consumer attach an instance to a tenant VPC without knowing anything about networking. NSO carries both and interprets neither.

Prepared, on the claim and the interface

The data plane's pre-workload artifacts exist, so a workload consuming this interface can be created. Owned by whoever realizes the interface, seeded Unknown and then left alone, exactly as Programmed already is.

The distinction between the two conditions is the point, and getting it backwards deadlocks the platform. Prepared becomes true before any workload exists, which is what makes waiting on it safe. Programmed only becomes true when the interface is attached, which happens while the workload's sandbox is being created — so a consumer that withholds the workload until Programmed is true waits for something its own waiting prevents. That is stated on both condition constants and in the enhancement, because the next person to gate on one of them will read one of the two.

Ready now derives from Bound + Allocated + Prepared + Programmed. The existing survival test is extended to walk both conditions in order rather than a parallel test being added.

NetworkInterfaceClaim.spec.attachmentMode

Netns or Hypervisor, defaulting to Netns, copied verbatim onto NetworkInterface.spec.attachmentMode at fulfillment. It says how the guest consumes the NIC — placed in a network namespace, as an ordinary container expects, or handed to a hypervisor as a device, as a virtual machine or microVM guest needs. It names no CNI, no Multus and no Linux device type, so it stays meaningful on a platform that has none of those. Immutable on the claim, because both the guest and the attachment are built against it.

Nothing sets it to Hypervisor yet. The first consumer is a VPC controller that takes the value from its own required configuration, standing in for a compute capability class that does not exist as an API yet.

Withdrawn from an earlier revision of this PR

NetworkInterface.status.consumerAnnotations is gone. It put an instruction in a status field, assumed the consumer was a Kubernetes Pod, and its opacity was fiction — the value was k8s.v1.cni.cncf.io/networks in plain sight on a published API, so every reader learned Multus exists whether or not their code was typed against it. A typed reference to the NAD was considered and rejected too: it compresses the same knowledge into a kind-to-mechanism switch, and once a mutating webhook exists the field has no external reader. Delivery now happens in a Pod admission webhook served by the VPC controller, and NSO's API carries no CNI vocabulary of any kind.

Tests

make lint clean. All non-e2e packages pass.

internal/controller was at the edge of Go's 10m per-package default before this work and is the reason to keep an eye on new envtest cases: it now runs in 537s, back inside the limit. Dropping the withdrawn field's test is what recovered the margin — this revision adds no new envtest case, extending an existing one instead.

Related

• Umbrellas: Integrate IPAM and compute networking interface #164, Integrate with network services operator for IP address assignment compute#112
• First consumer: feat(vpc): add the VPC controller that realizes attachments on the data plane cloud#6
• Siblings: Publish the bound NetworkInterface on Instance status compute#245, Gate the network on Prepared, never on Programmed compute#244

🤖 Generated with Claude Code