Separate host provisioning and node bootstrap into CAPI providers, following the Metal3/CAPM3 model

[arsdragonfly]

Proposal

Could Unbounded expose its host-provisioning and node-bootstrap capabilities as independently usable Cluster API infrastructure and bootstrap providers, while keeping cross-site networking separate?

The goal would be to preserve Unbounded's specialized capabilities without requiring users to adopt a parallel Kubernetes machine-lifecycle framework.

Metal3 As A Reference

Metal3 and Cluster API Provider Metal3 (CAPM3) demonstrate a useful separation:

• Bare Metal Operator and Ironic manage host inventory, inspection, imaging, cleaning, and power operations.
• CAPM3 implements CAPI infrastructure contracts, selecting a BareMetalHost and connecting its provisioning lifecycle to a CAPI Machine.
• A separate bootstrap provider, normally kubeadm, generates the configuration that initializes Kubernetes.
• CAPI coordinates Machine ownership, replacement rollouts, draining, and remediation.

A physical host is therefore distinct from its allocation as a Kubernetes Machine. Deleting a Machine can deprovision and release the host for reuse without deleting its inventory record.

This is particularly relevant to Unbounded's existing-server and bare-metal scenarios: adopting CAPI does not require treating physical servers as disposable cloud instances.

Applying This Separation To Unbounded

Unbounded currently combines host access/provisioning, Kubernetes join configuration, and lifecycle operations through its Machine, MachineOperation, controllers, and agent.

Could these responsibilities be separated along the following boundaries?

Layer	Proposed responsibility
Host management	Retain Machina/Metalman capabilities such as SSH, PXE, Redfish, imaging, and enrollment
CAPI infrastructure provider	Claim or provision a host, deliver bootstrap data, report infrastructure identity/status, and clean up or release the allocation
CAPI bootstrap provider	Generate Unbounded agent configuration and first-boot data for a particular Machine and target cluster
Host runtime	Prepare and run the nspawn worker environment and maintain required local boot services
Networking	Continue managing sites, gateways, and cross-site connectivity independently
CAPI	Own the Kubernetes Machine lifecycle and coordinate rollout, drain, and remediation

For cloud VMs, existing infrastructure providers such as CAPZ or CAPA could be reused where compatible, rather than requiring Unbounded to implement another cloud provisioning and replacement stack.

Why Independent Providers Matter

Separating infrastructure from bootstrap would enable useful compositions:

• Existing cloud infrastructure providers with Unbounded bootstrap and networking.
• Unbounded SSH/PXE infrastructure with its own bootstrap provider.
• CAPM3-managed hardware with Unbounded bootstrap.
• Unbounded-provisioned hosts with another compatible bootstrap provider.

These would need explicit compatibility testing, not just matching resource names. In particular, an Unbounded infrastructure provider should consume the standard bootstrap-data contract rather than always generating its own join configuration.

The benefit is broader than installation: users could integrate with MachineDeployments, MachineHealthChecks, ClusterClass, and management-cluster migration through established contracts instead of maintaining custom synchronization between lifecycle frameworks.

Lifecycle Ownership

This proposal does not require removing low-level operations or standalone workflows.

Power control, imaging, cleanup, and resumable provisioning still belong in the infrastructure backend. Some MachineOperation functionality could serve as a provider's remediation or coordinated in-place-update mechanism.

For CAPI-owned Machines, however, those operations should not independently initiate competing upgrades or replacements. A bootstrap-only path should also avoid requiring a Kubernetes-facing lifecycle daemon unless a specific ongoing responsibility needs it.

CAPI would not automatically solve enrollment security, backend crash recovery, or limited physical capacity. Those remain provider responsibilities, with explicit policies for host reuse and replacement when no spare host is available.

Suggested First Milestone

1. Define the distinction between persistent host inventory and a CAPI Machine allocation.
2. Implement an Unbounded bootstrap provider with a bootstrap-only host execution mode.
3. Integrate one host backend through the CAPI infrastructure contract.
4. Demonstrate provisioning, Node association, replacement, drain, and release, including controller restarts during provisioning and deletion.
5. Document supported provider combinations and preserve standalone operation where needed.

Would the maintainers be open to a design proposal using the Metal3/CAPM3 separation as a reference?

The central request is to make Unbounded's host and networking capabilities composable through CAPI, rather than making another machine-lifecycle framework a prerequisite for using them.

Reference: Cluster API provider contracts.