Move versioned external IP types from common to sled-agent-types#10291
Merged
Conversation
bnaecker
approved these changes
Apr 21, 2026
Collaborator
bnaecker
left a comment
bnaecker
left a comment
There was a problem hiding this comment.
LGTM, thanks for straightening all this out. It's never felt quite right, and this is a solid improvement.
jgallagher
added a commit
that referenced
this pull request
Apr 21, 2026
This is staged on top of #10291 and is more of the same; it moves `NetworkInterface` and `NetworkInterfaceKind` out of `omicron-common` and into `sled-agent-types`. Both of these are used in multiple APIs: * nexus-lockstep (unversioned) * nexus-internal (client-side versioned) * sled-agent (server-side versioned) * nexus-external (server-side versioned) I think putting this at the "lowest level" API (sled-agent) is reasonable, although I'm surprised this type fully is visible in the external API (edit: I think this are only reachable under endpoints tagged with experimental `system/probes`). If at some point we want to split them, that would be fine. Doing this work revealed a couple of time bombs, both addressed in these changes: 1. `nexus-types-versions` was depending on `sled-agent-types` (implicitly "the latest version" of every type) instead of `sled-agent-types-versions`. I'm 99.9% sure this is wrong and would lead to pain as soon as we try to add a new version of any of the types referenced via that path: we'd add a new version to `sled-agent-types-versions`, update `latest` which updates `sled-agent-types`, at which point we're (implicitly) changing the definition of some old, pinned type inside `nexus-types-versions`. This PR changes that dependency to `sled-agent-types-versions` and uses explicit version numbers instead of the `latest` path. 2. `omicron-common` had a `ResolvedVpcFirewallRule` type, but `sled-agent-types` _also_ has a `ResolvedVpcFirewallRule`. `sled-agent-client` was using a progenitor `replace` directive pointed at `omicron-common`, but the API was using the type from `sled-agent-types`. This was okay because they happened to be identical, but I'm not sure what would have happened if we'd changed one and not the other. This PR removes the `omicron-common` one and changes everyone to use the one from `sled-agent-types` instead.
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.
This change moves these types from
omicron-commontosled-agent-types:Please double-check this, but I believe:
ExternalIps,SourceNatConfig, andSourceNatConfigErrordon't appear in any OpenAPI specExternalIp{,v4,v6}Configappears only in the sled-agent APISourceNatConfig{Generic,V4,V6}appear in the sled-agent API (versioned) and the nexus-lockstep API (unversioned)Given that, I think it's more consistent with RFD 619 to move these out of common and into sled-agent-types. Hopefully it also reduces confusion when folks are trying to figure out versioning and run across these types (as @hawkw bumped into earlier today).
There should be no functional changes, and there should be no API changes - I tried to move the different versions to the particular sled-agent-types modules where they were introduced.