Declarative Cloud-Init Injection on Provisioned Hosts

[PDCuong]

User Story

As a cluster operator I would like to inject fresh cloud-init userData/networkData into a BareMetalHost that is already provisioned—whether it was provisioned by Metal3 (externalProvisioner: false) or adopted into Ironic (externalProvisioner: true)—so that I can reboot the existing OS, run a new cloud-init script, and avoid a full OS reprovision.

Detailed Description

There is no built-in, declarative BMH API to:
1 .Update spec.userData/spec.networkData on a host in the Provisioned/Active state.
2. Trigger Ironic’s adopt + config-drive (deploy interface’s prepare & take_over) or a partial deploy (inject config-drive + reboot) directly from Kubernetes.
3. Do so without wiping or redeploying the existing OS image.

Currently, Changing spec.image currently triggers the full clean → deploy cycle and overwrites the disk, which is exactly what we want to avoid for simple cloud-init re-injection.

Anything else you would like to add:
Ironic already supports these workflows via CLI:

openstack baremetal node set-provision-state adopt --config-drive …

Custom deploy-steps skipping write_image + --config-drive

A declarative BMH or annotations (e.g. spec.cloudInitInject: true) would let BMO watch for changes, call the right Ironic action, and update status conditions

/kind feature

[metal3-io-bot]

This issue is currently awaiting triage.
If Metal3.io contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Rozzii]

I don't think this feature fits in the scope of BMO, we might add support for doing different operations on provisioned nodes as part of CAPM3 or parallel to CAPM3 but everything in BMO or below e.g. Ironic supposed to not touch the user space of provisioned systems or the running OS in any way.

[Rozzii]

/kind invalid

[metal3-io-bot]

@Rozzii: The label(s) kind/invalid cannot be applied, because the repository doesn't have them.

Details

In response to this:

/kind invalid

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Rozzii]

I will probably start working on a controller or some solution to introduce the possibility of executing scripts on the provisioned node and the that could be extended to handle specific use cases in a declarative way.

But it is possible to take an other direction and make CAPM3 compatible with something like system-upgrade-controller or other existing node life cycle management tools.

So to sum up it is a CAPM3 topic and it will require a lot of planning and consideration but I agree that there is a need to provide OS/node life cycle management native to the Metal3 stack.