Skip to content

bootstore type reorg PR 3/?: Split internal/external API types: add ExternalBfdMode#9906

Draft
jgallagher wants to merge 5 commits intomainfrom
john/shadow-external-types-1
Draft

bootstore type reorg PR 3/?: Split internal/external API types: add ExternalBfdMode#9906
jgallagher wants to merge 5 commits intomainfrom
john/shadow-external-types-1

Conversation

@jgallagher
Copy link
Contributor

BfdMode was defined in omicron_common::api::external, but was used in the external API, a few internal APIs, and serialized in the bootstore. This PR introduces ExternalBfdMode (external API only) and moves BfdMode (the rest) into omicron_common::api::internal::shared - future work in this chain of PRs will move it again (along with other serialized-in-the-bootstore types), but it has to land there for now.

This makes no changes to any internal or external OpenAPI specs - it's only adjusting internal representations.

Part of #9801. Staged on top of #9905.

As it evolved, #9570 made various changes to both the sled-agent types
crate and the sled-agent API. As it landed, though, it made one
versioning bump to sled-agent API (v20 - BGP) and two to the types crate
(v20 - lockstep API, v21 - BGP). This squishes the latter two down to
just one (v20 - BGP) for consistency with the API's versioning.
This is only used in the sled-agent -> Nexus RSS handoff request in the
Nexus lockstep API.
Copy link
Contributor

@sunshowers sunshowers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

Base automatically changed from john/move-external-port-discovery to main February 24, 2026 14:05
@jgallagher
Copy link
Contributor Author

I'm really second guessing this. The External... prefix is quite unsightly, and #9910 was quite painful / I'm not even sure it's correct.

I'd like to pursue basically the path we laid out in #9801 (comment), but skip the "duplicate types that are used in the external API", in favor of having the external API reuse the types directly from sled-agent-types. I think the "move the types out of common and into sled-agent" and "duplicate types used in the external API" are mostly orthogonal bits of work, so doing the "move common -> sled-agent" can be done without closing the door on duplicating external API types afterwards, if we decide at the end we still want to do that.

@jgallagher
Copy link
Contributor Author

I'm really second guessing this. The External... prefix is quite unsightly, and #9910 was quite painful / I'm not even sure it's correct.

For now I'm going to mark these PRs as drafts, and reorder other work to defer the external type duplicating.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants