-
Notifications
You must be signed in to change notification settings - Fork 22
client: re-export instance spec types for use in sled-agent #899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This might make things somewhat nicer when sled-agent re-exports these.
An explanation of ffeb813: In any case, ffeb813 fixes the Linux build; I'll figure out what's going on with my dev environment separately. (I also see this on the latest master, fwiw.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach makes sense to me, no major concerns!
} | ||
} | ||
|
||
impl From<&str> for SpecKey { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice :)
.into_backend_name() | ||
.into_string() | ||
.into(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow... 😵💫
Co-authored-by: Eliza Weisman <[email protected]>
Follow-up to #896. Using generated instance spec types in sled-agent's API has some substantial downsides:
Debug
impls. The native versions of these types manually implDebug
for these types, but their generated counterparts always derive Debug (and AFAIK there's no way to ask Progenitor not to add this derive).To get around these problems:
propolis_api_types
.replace
directives to the generated client that replace the generated versions ofInstanceSpecV0
,VersionedInstanceSpec
, andReplacementComponent
with their re-exported equivalents.This way, sled-agent can use the re-exported spec types internally and in its API. This reuses their manual
impl
s when they exist (solving problem 1) and avoids presenting generated JSON schema documentation when generating the sled-agent API document (solving problem 2).Remove the
JsonSchema
implementations for generated spec types, since they're no longer needed.Finally, fix a one-line clippy nit that started showing up alongside these changes.
Tests: cargo test and PHD; picked up this change into oxidecomputer/omicron#8002 and verified that (a) that change still works (and that it produces a much cleaner sled-agent API document), and (b) log messages from sled-agent redact spec components that we want to be redacted.
Footnotes
Concretely: suppose you have type
foo::Widget
with a doc comment, and you have afoo_server
crate with a Dropshot API that makes use of this type. If you generate an OpenAPI document from this API, and then use Progenitor to generate a client from that document,foo_client::types::Widget
will have a doc comment that includes both the originalfoo::Widget
doc comment and a Progenitor-generated description of the type's JSON schema. This is all well and good and what we expect. Now suppose you then create cratebar_server
and includefoo_client::types::Widget
in its Dropshot API. The description ofWidget
inbar_server
's API document will contain both the originalfoo::Widget
description and the generated JSON schema text fromfoo_client::types::Widget
in the type's "description" field. And if you then generatebar_client::types::Widget
, the schema will be generated again and re-included in the generated type's doc comment. Needless to say: yuck. ↩