vrr/Pulse
2
0
Fork 0
mirror of https://github.com/rcourtman/Pulse.git synced 2026-08-31 10:36:39 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 12

Light up guest OS column for Proxmox and vSphere workloads

Browse source 
useWorkloads.ts mapped guest OS info exclusively from
resource.agent.osName / agent.osVersion. Proxmox's resource
adapter populates resource.proxmox.osName / osVersion from
qemu-guest-agent's os-info readout (today: 25 of 45 mock VMs).
vSphere's adapter exposes guest OS family on
resource.vmware.guestOsFamily. Both fields were ignored by the
mapping, so the workload table's OS column rendered as blank on
every VM despite the data being right there in the API
response.

Extend the fallback chain:
  agent.osName ?? proxmox.osName ?? vmware.guestOsFamily
  agent.osVersion ?? proxmox.osVersion

Behavior change is additive: guests that already lit up the
column via agent.osName keep working unchanged; Proxmox VMs with
guest-agent reporting now show "Windows Server" / "Ubuntu" /
etc and vSphere VMs show the coarse "LINUX" / "WINDOWS" family.
The OS column stays hidden by default everywhere (its default
visibility belongs to the global workloads-controls hidden list,
not to this mapping), but when a user toggles it on from the
Columns menu it actually has data to show.

Surfaced by the cross-platform column audit (cf 24/05 session
log). The two corresponding platform-specific shape extensions
on APIResource (proxmox.{osName,osVersion},
vmware.guestOsFamily) document fields that the backend was
already shipping; this commit just teaches the typing and the
mapping to read them.
This commit is contained in:
rcourtman 2026-05-23 14:13:11 +01:00
parent d929ac6477
commit e5b31f4843
1 changed files with 13 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

15
frontend-modern/src/hooks/useWorkloads.ts
View file

@ -95,6 +95,8 @@ type APIResource = {
balloon?: number;
isOci?: boolean;
osTemplate?: string;
osName?: string;
osVersion?: string;
};
agent?: {
hostname?: string;
@ -137,6 +139,7 @@ type APIResource = {
runtimeHostName?: string;
managedObjectId?: string;
powerState?: string;
guestOsFamily?: string;
};
discoveryTarget?: {
resourceType?: string;
@ -462,8 +465,16 @@ const mapResourceToWorkload = (resource: APIResource): WorkloadGuest | null => {
disks: normalizeDiskArray(resource.proxmox?.disks ?? resource.agent?.disks),
diskStatusReason: undefined,
ipAddresses: resource.identity?.ipAddresses ?? [],
osName: resource.agent?.osName,
osVersion: resource.agent?.osVersion,
// Guest OS info: agent.osName/osVersion is the universal fallback the
// workload table reads. Proxmox writes to resource.proxmox.osName /
// osVersion (qemu-guest-agent os-info); vSphere surfaces a coarse
// family on resource.vmware.guestOsFamily (e.g. "LINUX", "WINDOWS"
// — there's no analogous "OS version" carve-out). Falling back here
// lights up the OS column for both platforms without changing what
// already-populated agent-driven rows render.
osName:
resource.agent?.osName ?? resource.proxmox?.osName ?? resource.vmware?.guestOsFamily,
osVersion: resource.agent?.osVersion ?? resource.proxmox?.osVersion,
agentVersion: resource.agent?.agentVersion,
networkInterfaces: mapNetworkInterfaces(resource.agent?.networkInterfaces),
networkIn: resource.metrics?.netIn?.value ?? 0,