Nexus should treat Propolises (not just instances) as sled services #2839
Comments
gjcolombo
added a commit
that referenced
this issue
Apr 14, 2023
Using instance IDs to reserve VMM resources on sleds is not quite flexible enough, because a single instance can have multiple Propolis VMMs. Use the Propolis ID as the key for these instead. Add a function to allow the deletion saga to fetch a previously-deleted instance record so that it can obtain this ID at the correct time. Simply returning the deleted record from the delete-record step is insufficient because the record- deleting step needs to be idempotent and, if it runs more than once, may not find any record to delete and return. Tested: cargo test. Will also do some ad hoc VM creations/deletions on a test cluster before merging. Fixes #2839. --------- Co-authored-by: Sean Klein <sean@oxide.computer>
This was referenced Oct 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Nexus uses instance IDs as the "service ID" primary key when accounting for an instance's resource consumption on a sled. This doesn't work well for live migration, where an instance can live on multiple sleds at once, or (in the extremely hypothetical case of an intra-sled migration) can have multiple independent Propolises on the same sled.
Fortunately, the actual service that consumes resources to provide a virtual machine--a Propolis process--has its own ID, so we can use that as the resource key instead.
The text was updated successfully, but these errors were encountered: