feat: Support Operating System labels

[hvenugopal-nv]

Summary

The OperatingSystem resource is one of the few NICo REST resources that has no labels field. We would like labels added to Operating System (create, read, update) so operators can tag OS images the same way they already tag Machines and other resources.

Current behavior (spec v1.6.0)

labels ($ref: #/components/schemas/Labels — a string→string map, maxProperties: 10) is already supported on:

Resource	Read	Create	Update
Machine	yes	n/a	yes
ExpectedMachine / ExpectedRack / ExpectedSwitch / ExpectedPowerShelf	yes	yes	yes
Instance / InstanceType	yes	yes	yes
VPC / NetworkSecurityGroup / InfiniBandPartition	yes	yes	yes
OperatingSystem	no	no	no

OperatingSystem today exposes only name, description, type, image/iPXE attributes, isCloudInit, phoneHomeEnabled, isActive, deactivationNote, allowOverride, siteAssociations and status fields. The only place to record arbitrary metadata is the free-text description, which is not queryable and not machine-readable.

Relevant operations:

• get-all-operating-system — GET /v2/org/{org}/nico/operating-system
• get-operating-system — GET /v2/org/{org}/nico/operating-system/{operatingSystemId}
• create-operating-system — POST /v2/org/{org}/nico/operating-system
• update-operating-system — PATCH /v2/org/{org}/nico/operating-system/{operatingSystemId}

Motivation

Other bare-metal platform providers we integrate with support tagging of OS images natively:

• OpenStack — Glance images carry arbitrary image properties plus image tags, commonly used for scheduling/compatibility hints and for marking curated images.
• BCM (Base Command Manager) — software images/categories carry metadata used to express which node hardware an image applies to.

Without an equivalent in NICo, consumers building on top of the REST API have to keep OS metadata in an external side-table keyed by OS UUID, which drifts from the source of truth and cannot be shared across tenants of the same provider.

Concrete things we want to express as labels on an Operating System:

1. Machine-type / hardware compatibility — which machine or instance types the image is valid for, so a portal or scheduler can filter the OS list to images that will actually boot on the selected hardware (e.g. compatible-machine-type=gb200-nvl72).
2. Blessed / tested state — whether the image has passed qualification (e.g. validation=blessed, validation=untested), so UIs can visually separate curated images from experimental ones.
3. Lifecycle / release channel — channel=stable|beta|deprecated, plus a target removal date for deprecated images.
4. Ownership and support — owning team or support tier, useful for triage when a provisioning failure traces back to a specific image.

Because these are provider-defined semantics, a free-form Labels map is the right shape — same as Machine.labels — rather than new typed fields.

Proposed change

1. Add labels ($ref: #/components/schemas/Labels) to:

   • OperatingSystem
   • OperatingSystemCreateRequest
   • OperatingSystemUpdateRequest

   Matching the existing Machine.labels semantics on update — the map is overwritten, so callers include existing labels to preserve them — and matching the existing authorization model where the Provider (or a privileged Tenant) can set labels.

2. Optionally, add a label query parameter to get-all-operating-system for server-side filtering (e.g. ?label=validation%3Dblessed). No resource in the API supports label-based filtering today, so this is a broader addition; if it is preferable to handle it separately we are happy for it to be split into its own issue. Returning labels on the existing endpoints is the part we need first.

Prior art in this API

NVIDIA/infra-controller-rest#381 — feat: Support InfiniBand Partition labels — added the same field to InfiniBandPartition. We are asking for the equivalent on OperatingSystem.