MVP Inventory Flow
Figma document
This is a draft proposed flow for the MVP Inventory pages. At this time, feedback should be focused on inventory over sled reboot and migration as the process for this is still to be determined in RFD 378.
Here we see a list of sleds, their status, running & stopped VMs, allocation, and version.
Are we assuming that a stopped VM no longer contributes to the allocated resources on a sled?
But if the instance is stopped and doesn't exist on any sled, this will try to create the instance on the sled on which it most recently ran, which might not have capacity for it (even though some other sled might). This function should distinguish the "instance already incarnated" and "instance stopped" cases and select a new sled in the latter case.
oxidecomputer/omicron#2315 (comment)
We're showing the allocated resources as a fuzzy proportion of total resources, since some amount of this is used by the system.
Version here is a version or a version and a target version if a sled is in the middle of updating.
We're showing a banner that is letting the operator know that instances need to be migrated before a sled can reboot and finish the update process. In practice this depends on the outcome of RFD 378#_proposed_solutions as to the level of intervention needed from an operator.
Switches are shown for completeness, perhaps in the future we can include further metrics.
Here we see a sled detail page. This includes a list of instances, scoped by silo and project since instance names are not unique. Whilst we have started to explore the process of migrating individual instances to other sleds, but this likely change as work on migration progresses.
When our fault management has been developed further we can introduce issues into the sled detail page.
The utilization page shows resource utilization for the selected sled.
MVP Inventory Flow
Figma document
This is a draft proposed flow for the MVP Inventory pages. At this time, feedback should be focused on inventory over sled reboot and migration as the process for this is still to be determined in RFD 378.
Here we see a list of sleds, their status, running & stopped VMs, allocation, and version.
Are we assuming that a stopped VM no longer contributes to the allocated resources on a sled?
We're showing the allocated resources as a fuzzy proportion of total resources, since some amount of this is used by the system.
Version here is a version or a version and a target version if a sled is in the middle of updating.
We're showing a banner that is letting the operator know that instances need to be migrated before a sled can reboot and finish the update process. In practice this depends on the outcome of RFD 378#_proposed_solutions as to the level of intervention needed from an operator.
Switches are shown for completeness, perhaps in the future we can include further metrics.
Here we see a sled detail page. This includes a list of instances, scoped by silo and project since instance names are not unique. Whilst we have started to explore the process of migrating individual instances to other sleds, but this likely change as work on migration progresses.
When our fault management has been developed further we can introduce issues into the sled detail page.
The utilization page shows resource utilization for the selected sled.