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
sled-agent: move instance configuration generation to Nexus (#8002)
One of the determinations in RFD 505 is that Nexus should be the
component that's in charge of determining how to configure a VM given a
set of database records describing its instance (the Instance itself,
its attached Disks and NetworkInterfaces, etc.). To summarize the
rationale in the RFD, the hope is that this will promote two nice
properties:
- **Local reasoning about virtual platforms**: All the logic that
translates instance descriptions into VM specs now lives in a single
module in Nexus. In past iterations of the code, Nexus transformed
database records into an intermediate sled-agent type, and sled-agent
would transform those into Propolis API types, which Propolis would then
use to fill in virtual hardware details. Understanding where a VM's
configuration came from required the reader to look at all these
components; now all the relevant logic lives in Nexus.
- **Serviceability**: Putting type transformations and platform policies
into sled-agent and Propolis makes them marginally more painful to
update, since updating these components requires the system to migrate
VMs and reboot sleds. Putting the virtual platform policy in Nexus will
make it much less expensive to update in the future.
To achieve this:
- Move sled-agent's virtual platform logic (added in #7211) into a new
Nexus module. Sled-agent needs to hold onto a bit of logic to insert
OPTE port names into instance specs before sending those specs to
Propolis; this needs to live in the agent since it selects the relevant
object names.
- Update the sled-agent instance registration API to take a Propolis
instance spec as a parameter (and rework some other types to distinguish
a bit more clearly between "Propolis VM configuration" and "sled-agent
objects that need to be created to support this VM").
Tested by booting a VM in a dev cluster, booting a comparable VM on
rack2, and comparing their instance specs (as returned by Propolis's
`/instance/spec` API) to make sure they specified the same components
with the same configuration.
0 commit comments