Ask the network for the attachment a runtime class needs - #301
Merged
Conversation
privateip
previously approved these changes
Sep 11, 2026
scotwells
marked this pull request as ready for review
September 11, 2026 23:55
A general-purpose guest and a unikernel guest both take a hypervisor interface, but their runtimes learn about the device differently. Nothing compute created said so, so the networking layer had only a cell-wide setting to go on and every guest in a cell was attached the same way. The provider that publishes a runtime class now states how guests in that class take an interface, so adding a class stays one declarative act with no configuration to edit and no rollout anywhere. The catalog is readable only where deployments are created, so the answer is resolved there and carried to the cell, which asks the networking layer for it when it claims an interface. A class that states nothing, which is every class published today, asks for nothing and leaves the cell deciding exactly as it does now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
scotwells
force-pushed
the
feat/runtime-class-network-attachment
branch
from
September 11, 2026 23:58
6b0456a to
072f132
Compare
privateip
approved these changes
Sep 12, 2026
This was referenced Sep 12, 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.
General-purpose instances and unikernel instances both run under a hypervisor, but their runtimes differ in how they learn that a network device exists. Compute said nothing about this, so the networking layer had only a single cell-wide setting to work from and every guest in a cell was attached the same way. A cell that serves both tiers cannot get both right.
The provider that publishes an execution tier now states how guests in that tier take a network interface, alongside everything else it publishes about the tier. Adding a tier stays a single declarative act: nothing to configure, nothing to roll out. Because the tier catalog is readable where a deployment is created and not inside a cell, the answer is resolved once and travels with the deployment to the cell that acts on it. What each instance ends up with is fixed for its lifetime, so an instance cannot have its attachment changed after its guest has booted, and correcting a tier moves new instances without disturbing running ones.
This is a no-op everywhere. A tier that states nothing asks for nothing and leaves the cell deciding exactly as it does today, and every tier published today states nothing. Only the general-purpose tier should ever state a value: stating one on the unikernel tier would override the cell-wide setting for every existing cell at once, which is why the published tier must be left as it is.
The tier object now carries the published contract plus the minimum the platform needs to wire an instance, which its documentation previously did not allow for. Opaque provider parameters stay excluded, since this value is read by the platform and drawn from a closed set rather than handed to a runtime.
Merge order is datum-cloud/network-services-operator#450, then this, then datum-cloud/cloud#20. A follow-on in the Kata provider will state the value on the general-purpose tier. This branch is temporarily pinned to the networking revision until it merges. Related to #259 and #260.
Testing
Build, vet, full unit suite and linters pass, with new tests covering resolution from the catalog, the disabled case, and what a cell asks for.
🤖 Generated with Claude Code