Which component does this relate to?
API types, BMC management, BIOS settings, server discovery
What is the reason for this feature request or change?
Many servers in our fleet are managed by OpenStack Ironic and have no corresponding BMC/Server objects in metal-api. These servers still have accessible BMC hardware and would benefit from metal-operator's settings management (BMCSettings, BIOSSettings,
BMCUser). However, they must not be subject to metal-operator's lifecycle management: power on/off, PXE boot, deployment, state machine transitions, or claiming.
There is currently no way to represent "I know this server exists and can reach its BMC, but an external system controls its lifecycle." The existing escape hatches are too blunt:
- metal.ironcore.dev/operation: ignore — skips all reconciliation, including settings
- spec.unclaimable: true — prevents claiming but the server remains fully lifecycle-managed
Describe the feature
A new cluster-scoped UnmanagedServer CRD representing a server whose lifecycle is owned by an external system (e.g. Ironic), but whose BMC is accessible for hardware settings management. A minimal UnmanagedServer controller would keep status in sync
(PowerState, Model, Manufacturer, BIOSVersion) via Redfish reads, with no state machine and no power operations.
BIOSSettings would gain an optional spec.unmanagedServerRef field alongside the existing spec.serverRef. When targeting an UnmanagedServer, the controller skips ServerMaintenance creation and instead uses a lightweight annotation gate: it waits for
metal.ironcore.dev/maintenance-ready=true on the UnmanagedServer (set by external automation / Ironic workflow), applies settings, then clears the annotation.
BMCSettings and BMCUser are unchanged — they already target BMC objects directly and work as-is when the UnmanagedServer references an existing BMC via spec.bmcRef.
Open design questions:
- Annotation gate vs. dedicated object — should the maintenance signal be an annotation on UnmanagedServer, or a thin UnmanagedServerMaintenance CRD consistent with ServerMaintenance?
- Fan-out — should BIOSSettingsSet gain a spec.unmanagedServerSelector to fan out to matching UnmanagedServer objects?
- Inline credentials vs. BMCRef only — requiring a BMC object to always exist is simpler and reuses all BMC-level tooling (event subscriptions, firmware management); inline credentials add flexibility for Ironic servers that have no BMC object today.
Which component does this relate to?
API types, BMC management, BIOS settings, server discovery
What is the reason for this feature request or change?
Many servers in our fleet are managed by OpenStack Ironic and have no corresponding BMC/Server objects in metal-api. These servers still have accessible BMC hardware and would benefit from metal-operator's settings management (BMCSettings, BIOSSettings,
BMCUser). However, they must not be subject to metal-operator's lifecycle management: power on/off, PXE boot, deployment, state machine transitions, or claiming.
There is currently no way to represent "I know this server exists and can reach its BMC, but an external system controls its lifecycle." The existing escape hatches are too blunt:
Describe the feature
A new cluster-scoped UnmanagedServer CRD representing a server whose lifecycle is owned by an external system (e.g. Ironic), but whose BMC is accessible for hardware settings management. A minimal UnmanagedServer controller would keep status in sync
(PowerState, Model, Manufacturer, BIOSVersion) via Redfish reads, with no state machine and no power operations.
BIOSSettings would gain an optional spec.unmanagedServerRef field alongside the existing spec.serverRef. When targeting an UnmanagedServer, the controller skips ServerMaintenance creation and instead uses a lightweight annotation gate: it waits for
metal.ironcore.dev/maintenance-ready=true on the UnmanagedServer (set by external automation / Ironic workflow), applies settings, then clears the annotation.
BMCSettings and BMCUser are unchanged — they already target BMC objects directly and work as-is when the UnmanagedServer references an existing BMC via spec.bmcRef.
Open design questions: