You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several swaths of types, relating to instance specs and the serial console, defined in the propolis-client lib today. Some of those are then re-exported in that same library from the code generated by progrenitor, based of the openapi json defined by propolis-server. While the handmade client code in propolis-client served a purpose early-on, as the progenitor-based bits were still being hammered out, we should clean that up so that its little more than the progenitor definition, plus whatever small helpers we deem necessary.
Types exposed by the openapi-visible portion of propolis-server should go in some sort of crate or module, used only by propolis-server (and perhaps the mock-server), rather than living in propolis-client. This will cut down on the dependencies required by propolis-client consumers as well.
The text was updated successfully, but these errors were encountered:
There are several swaths of types, relating to instance specs and the serial console, defined in the
propolis-client
lib today. Some of those are then re-exported in that same library from the code generated by progrenitor, based of the openapi json defined bypropolis-server
. While the handmade client code inpropolis-client
served a purpose early-on, as the progenitor-based bits were still being hammered out, we should clean that up so that its little more than the progenitor definition, plus whatever small helpers we deem necessary.Types exposed by the openapi-visible portion of
propolis-server
should go in some sort of crate or module, used only bypropolis-server
(and perhaps the mock-server), rather than living inpropolis-client
. This will cut down on the dependencies required bypropolis-client
consumers as well.The text was updated successfully, but these errors were encountered: