feat: a cell tells compute which location it serves - #227
Merged
Conversation
A cell could not tell users where their workload was running. Compute asked the cell for a Location matching the deployment's city, but Locations do not exist on cells, so the answer was always "no location" and every instance ran without one. Cells are now delivered a ServingLocation naming the place they sit in; read that instead. This also makes a misplaced deployment visible for the first time. A deployment that reaches a cell serving another city now says so, and is held out of service rather than quietly running in a city nobody asked for. A cell that has not been identified yet still runs workloads, it just reports what it is waiting for. Instances now carry their location from the moment they are created, and any instance that predates the cell learning where it is gets it backfilled. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scotwells
marked this pull request as ready for review
August 14, 2026 12:56
NSO #373 gives a network a presence in every location it is used, and adds the claim rejection reasons that come with it. Compute passes those reasons through verbatim, so picking them up needs no code change. The same change drops LocationReference.Namespace: Locations are cluster scoped, so the field was always empty. Dropping it from the index key and the CRDs removes a namespace nobody could ever have set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scotwells
enabled auto-merge
August 14, 2026 14:21
ecv
approved these changes
Aug 14, 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.
A cell now learns which location it serves by reading, rather than by compute guessing from a catalog that was never delivered to it.
What changes
A deployment in the wrong place says so. Until now a workload delivered to the wrong cell was invisible — it would come up in a city the user never asked for. That is now reported as what it is: a delivery fault, not a user error.
A cell that has not been told where it is explains how to fix it. The old message said no locations were registered with the system, which sent people looking in the wrong place. It now names what the cell is missing.
A cell given two locations refuses to guess. Picking one would place workloads somewhere nobody chose.
In each of these cases instances wait rather than come up somewhere unintended, and they proceed on their own the moment the fault clears. Nothing needs an operator.
An instance knows where it is running. Instances created before a cell resolved its location never learned it, and nothing ever told them. They do now, and the ones already running are filled in.
Why now
Compute looked up a location in a catalog that is not present on any cell. That was harmless only because the networking integration is switched off, and wrong the moment it is switched on. datum-cloud/network-services-operator#372 delivers each cell the one location it serves, so the answer is now something a cell can simply read.
Notes
Nothing changes for a customer, and nothing is switched on here. The networking integration remains off.
Also re-pins network-services-operator to a released main, replacing the temporary pin taken in #224.
Related