Problem
The existing IPI extra-worker flow is coupled to NUM_EXTRA_WORKERS/NUM_ARM_WORKERS and the libvirt inventory generated by 02_configure_host.sh. generate_ocp_host_manifest() can render a minimal Secret and BareMetalHost, but there is no independent input for a real, externally managed physical worker.
A common development topology is:
- control-plane VMs created by dev-scripts;
- a physical worker whose host/admin NIC is on a routed network;
- a real Redfish BMC reachable on that network;
- virtual-media provisioning through the external network; and
- host-specific pre-provisioning nmstate for selecting the correct NIC.
Today users must hand-create the network-data Secret and enrich the BMH with fields such as preprovisioningNetworkDataName, customDeploy, rootDeviceHints, userData, labels, and an existing BMC credential Secret reference. They must then manually apply and monitor the resources.
Proposed scope
Add an external-worker inventory path that is independent of libvirt VM counts and can render, but does not automatically provision, offline BMH resources. The generic input should support:
- BMH name, architecture, boot MAC, and full BMC address;
- an existing BMC credential Secret reference (no credential values in generated output);
- optional labels and root-device hints;
- optional pre-provisioning nmstate rendered into a Secret;
customDeploy.method and userData; and- offline-by-default enrollment.
A follow-up can add an explicit day-2 action that applies the resources, waits for inspection, and provisions serially with deterministic host selection. Disk-destructive provisioning should not be part of the manifest-rendering change.
Non-goals
Why this belongs in dev-scripts
It fills the gap between a dev-scripts-created IPI control plane and real physical day-2 workers while reusing the existing Metal3/BMH workflow. It is also useful for mixed-architecture and external-hardware CI environments.
Problem
The existing IPI extra-worker flow is coupled to
NUM_EXTRA_WORKERS/NUM_ARM_WORKERSand the libvirt inventory generated by02_configure_host.sh.generate_ocp_host_manifest()can render a minimal Secret and BareMetalHost, but there is no independent input for a real, externally managed physical worker.A common development topology is:
Today users must hand-create the network-data Secret and enrich the BMH with fields such as
preprovisioningNetworkDataName,customDeploy,rootDeviceHints,userData, labels, and an existing BMC credential Secret reference. They must then manually apply and monitor the resources.Proposed scope
Add an external-worker inventory path that is independent of libvirt VM counts and can render, but does not automatically provision, offline BMH resources. The generic input should support:
customDeploy.methodanduserData; andA follow-up can add an explicit day-2 action that applies the resources, waits for inspection, and provisions serially with deterministic host selection. Disk-destructive provisioning should not be part of the manifest-rendering change.
Non-goals
Why this belongs in dev-scripts
It fills the gap between a dev-scripts-created IPI control plane and real physical day-2 workers while reusing the existing Metal3/BMH workflow. It is also useful for mixed-architecture and external-hardware CI environments.