Skip to content

Add generic devices to WorkloadStatus #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
clupuishere wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add generic devices to WorkloadStatus #32

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c490581
Add generic devices to WorkloadStatus
clupuishere Jun 9, 2026
4fe3b34
Introduce mount scope types
clupuishere Jun 17, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions protect/control/v1/common.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -423,6 +423,7 @@ message WorkloadStatus {
WorkloadMountStatus mount_status = 5;
google.protobuf.Timestamp created_at = 6;
WorkloadPciDeviceStatus pci_device_status = 7;
WorkloadDeviceStatus device_status = 8;

@bleggett bleggett Jun 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this conceptually differ from the existing

  • WorkloadBlockDeviceStatus
  • WorkloadPciDeviceStatus
  • WorkloadMountStatus

?

Do we need all three? If we do, why?

@clupuishere clupuishere Jun 11, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}

message WorkloadBlockDeviceInfo {
Expand All @@ -433,6 +434,10 @@ message WorkloadBlockDeviceInfo {
bool loop_dev = 5;
}

message WorkloadFsDeviceInfo {
uint64 device_id = 1;
}

message WorkloadPciDeviceInfo {
string location = 1;
}
Expand All @@ -445,11 +450,30 @@ message WorkloadPciDeviceStatus {
repeated WorkloadPciDeviceInfo devices = 1;
}

message WorkloadDeviceInfo {
oneof info {
WorkloadBlockDeviceInfo block = 1;
WorkloadFsDeviceInfo fs = 2;
WorkloadPciDeviceInfo pci = 3;
}
}

message WorkloadDeviceStatus {
repeated WorkloadDeviceInfo devices = 1;
}

enum WorkloadMountScopeType {

@bleggett bleggett Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@clupuishere clupuishere Jun 29, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Xen
  • WORKLOAD_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.

WORKLOAD_MOUNT_SCOPE_TYPE_UNKNOWN = 0;
WORKLOAD_MOUNT_SCOPE_TYPE_ZONE = 1;
WORKLOAD_MOUNT_SCOPE_TYPE_WORKLOAD = 2;
}

message WorkloadMountInfo {
string tag = 2;
string host_path = 3;
string target_path = 5;
bool read_only = 6;
WorkloadMountScopeType scope = 7;
reserved 1, 4;
}

Expand Down
Loading