Add generic devices to WorkloadStatus#32
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).
|
| WorkloadMountStatus mount_status = 5; | ||
| google.protobuf.Timestamp created_at = 6; | ||
| WorkloadPciDeviceStatus pci_device_status = 7; | ||
| WorkloadDeviceStatus device_status = 8; |
There was a problem hiding this comment.
How does this conceptually differ from the existing
WorkloadBlockDeviceStatusWorkloadPciDeviceStatusWorkloadMountStatus
?
Do we need all three? If we do, why?
There was a problem hiding this comment.
For the long term, it should replace Workload{Block,Pci}DeviceStatus. Regarding WorkloadMountStatus that's a different (open) discussion given that it's related to filesystems and not to devices.
We are introducing WorkloadDeviceStatus and WorkloadDeviceInfo to define handlers for managing devices in an uniform and generic way. We have been rolling so far with standalone message types for block (WorkloadBlockDeviceInfo message type) and PCI (WorkloadPciDeviceInfo message type) devices and adding support for a new device type (WorkloadFsDeviceInfo message type) raises an immediate need to have a more scalable and generic way of handling devices. Signed-off-by: Costin Lupu <costin@edera.dev>
When sharing host directories, we can either use an unified mount per zone or a mount for each workload. Signed-off-by: Costin Lupu <costin@edera.dev>
| repeated WorkloadDeviceInfo devices = 1; | ||
| } | ||
|
|
||
| enum WorkloadMountScopeType { |
There was a problem hiding this comment.
It's still not clear to me why we have a non-workload scoping policy enum on a workload-scoped type, or why it is necessary that we leak this internal mount policy stuff into the public control API?
I do not think we actually need this policy scope enum in the public control API.
There was a problem hiding this comment.
WorkloadMountScopeType defines the options that are available for mounting a workload volume:
WORKLOAD_MOUNT_SCOPE_TYPE_ZONE- all the workloads mounts are relying on a unified zone mount which aggregates all the workload mounts and which, behind the scenes, is using a single backend for all the workloads; this is the current behavior on XenWORKLOAD_MOUNT_SCOPE_TYPE_WORKLOAD- each workload has its own independent scope, backed by its own backend; this is the behavior used on KVM
So the WorkloadMountScopeType defines the scope where the workload mounts live, which makes it a workload related info even when the scope is per zone.
Now, this is not the only info that lives in the public control API and that's relevant only internally. This approach has been used in the past as well, e.g. WorkloadMountInfo.tag or WorkloadBlockDeviceInfo.loop_dev.
3 participants
The current changes are needed to add support for mounts per workload. Since we are introducing a new type of devices, filesystem devices, we need a more generic way of handling devices. With filesystem devices we can share host directories either as unified mounts per zone or as one mount per workload.