feat: a workload asks for its network where it runs - #231
Merged
Conversation
A workload that lands in a location needs its network to exist there before an instance can get an address. Compute now says so: once a cell reports the location it serves a deployment from, the federator writes a NetworkBinding next to the hub WorkloadDeployment. NSO folds every binding for the same network and location into one shared NetworkContext and propagates it to the cells serving that location, where the interface claim path reads it. The binding is one per WorkloadDeployment and owned by the hub copy, so the hub releases it with its owner and nothing in compute counts the other consumers of a shared presence. Compute stamps only the network and location labels, via a merge patch computed from the live object, leaving the network UID NSO records on the binding untouched. What NSO refuses — an unresolvable project, a missing network, a location the project cannot use — is reported on the deployment's Available condition and acted on nowhere else. Instances stay gated on their own interface claims: a binding waiting on a context must never take a running deployment apart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scotwells
marked this pull request as ready for review
August 14, 2026 18:22
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
2 participants
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.
A workload deployed to a location now asks for its network to be there.
Until now nothing did. An instance would come up in a city, ask for an address, and be told the network it named is not available there — with no way for it to become available.
What changes
When a deployment lands somewhere, it says it needs its network at that location. Several deployments wanting the same network in the same place share one presence, and none of them has to know the others exist.
Nothing new to write, and nothing customer-facing changes. This ships behind the networking feature gate, which stays off.
When a network cannot be had there
The deployment says so, in the terms of the actual problem — the location is not available, the network does not exist, the project could not be resolved. An instance stuck behind a network that never arrived is a new way to be stuck, and it should not read as a scheduling failure.
What deliberately does not happen
A network's presence going quiet does not tear anything down. Addresses stay allocated and instances keep running; it only means do not attempt a new attachment. Treating a brief interruption as a teardown signal would turn it into an outage.
Related