Label network interface claims so a network service can select them - #252
Merged
Conversation
A networking NetworkService selects its members by label on the NetworkInterfaceClaim, but compute stamped no labels on the claims it creates, so no selector could ever match one. Stamp the well-known keys consumers select on at creation, sourced from the WorkloadDeployment that drove the instance. Claims created before this change would never gain the labels, because the ensure path returns on a Get hit and never writes: nearly every claim spec field is immutable once addresses are allocated against it. Labels are not, so an existing claim is brought up to date with an additive merge patch that touches metadata only. The patch adds just the keys compute owns, leaving networking's own labels on the same object intact. Key changes: - Stamp workload-name, placement-name, city-code, and instance-index on every claim compute creates - Backfill those labels onto an existing claim when absent or stale, leaving the immutable spec untouched - Omit a key whose source is empty rather than stamping it blank
scotwells
marked this pull request as ready for review
August 26, 2026 14:02
savme
approved these changes
Aug 26, 2026
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.
Compute half of Network Services. Draft: prototype supporting that design, not a merge candidate. The networking half is network-services-operator#411.
Why
A consumer will soon be able to put an application behind a hostname and have the edge load balance across every location it runs in. That works by selecting the network interface claims behind a workload, which means the claims have to say which workload they belong to.
They carry no labels today, so nothing can select them.
What changes
Compute stamps four keys it already defines on every
NetworkInterfaceClaimit creates: workload name, placement name, city code and instance index. All four already appear on Instances, so no new vocabulary is introduced.A consumer then selects an application by naming one label, and never labels anything themselves.
Two details worth review
Claims are created once and never updated, because their spec is immutable. Labels are not, so an existing claim missing them acquires them through a patch that touches metadata only. The spec-building path is untouched.
A key whose source is empty is omitted rather than written blank, so a selector on it matches nothing rather than matching every claim that lacks a value.
Scope
No API change and no behaviour change for anything that does not select claims. Instances, scheduling gates and the federation path are untouched.