Question on completion boundaries across the BareMetalHost lifecycle
Jeleel Muibi
Hi all,
Dmitry Tantsur suggested I bring this question here.
I’m looking at a lifecycle boundary around infrastructure operations that span more than one system, and I’m comparing it with Metal3/BareMetal Operator behaviour.
In BMO, inspection, cleaning and provisioning each have their own lifecycle state. My question is:
When those controller-local states are individually valid, when would a separate wider host-operation completion boundary add useful safety, and when would it simply duplicate BMO’s reconciliation?
A counterexample would be especially useful: is there a BareMetalHost transition or failure mode where treating the locally reported state as completion of the wider operation would be wrong?
This came up while looking at the ExternallyProvisioned → Provisioned lifecycle boundary and related inspection/cleaning behaviour.
Optional context for the wider runtime question I’m testing:
https://github.com/hybridops-tech/hybridops-core/issues/269
A short view is more than enough.
Best,
Jeleel
Dmitry Tantsur
--
You received this message because you are subscribed to the Google Groups "Metal3 Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/metal3-dev/a8882d58-f533-45bb-a91e-1599e0788e3bn%40googlegroups.com.
--
Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty
Jeleel Muibi
Hi Dmitry,
Thanks. I probably made the wording more abstract than it needed to be.
What I mean is something outside the BareMetalHost/Ironic state machine deciding whether the wider user-requested operation is actually done.
For example, if the request is to prepare a host for a cluster, Metal3/Ironic would still own inspection, cleaning and provisioning. But if the host reaches the expected Metal3 state and a required handoff or readiness check then fails, I wouldn’t want the wider operation to be reported as complete.
So the question is really whether having that outer completion check is useful around Metal3, or whether the BareMetalHost state should normally be enough and anything outside it should just react to that state.
If you think the latter is the better model, or there’s a case where the outer check would just duplicate Metal3, that would be useful to understand.
Jeleel
Zane Bitter
> Hi Dmitry,
>
> Thanks. I probably made the wording more abstract than it needed to be.
> What I mean is something outside the BareMetalHost/Ironic state machine
> deciding whether the wider user-requested operation is actually done.
>
> For example, if the request is to prepare a host for a cluster, Metal3/
> Ironic would still own inspection, cleaning and provisioning. But if the
> host reaches the expected Metal3 state and a required handoff or
> readiness check then fails, I wouldn’t want the wider operation to be
> reported as complete.
>
> So the question is really whether having that outer completion check is
> useful around Metal3, or whether the BareMetalHost state should normally
> be enough and anything outside it should just react to that state.
asked for to disk and rebooted. If you want that thing to actually run
(and generally most people do) then it's too soon to declare victory
once provisioning is complete. For example, if you look at CAPI it
tracks the BareMetalHost status but waits until the host has started
kubelet and joined the cluster as a k8s Node before moving the Machine
to the Running phase. It's easy to imagine an equivalent if you are
provisioning the host to be something other than a k8s Node.
I have no idea if this answers your question or not :)
cheers,
Zane.
> outer check would just duplicate Metal3, that would be useful to understand.
>
> Jeleel
>
>
> On Thursday, August 20, 2026 at 2:29:40 PM UTC+1 dtan...@redhat.com wrote:
>
> Hi,
>
> Sorry for the lack of answers so far. I think we need a few more
> details on what you're trying to accomplish. For example, I'm not
> sure what "a separate host-operation completion boundary" means both
> in technical terms and for end users.
>
> Dmitry
>
> On Sat, Aug 15, 2026 at 2:28 PM Jeleel Muibi <jelo...@gmail.com> wrote:
>
> Hi all,
>
> Dmitry Tantsur suggested I bring this question here.
>
> I’m looking at a lifecycle boundary around infrastructure
> operations that span more than one system, and I’m comparing it
> with Metal3/BareMetal Operator behaviour.
>
> In BMO, inspection, cleaning and provisioning each have their
> own lifecycle state. My question is:
>
> useful safety, and when would it simply duplicate BMO’s
> A counterexample would be especially useful: is there a
> BareMetalHost transition or failure mode where treating the
> locally reported state as completion of the wider operation
> would be wrong?
>
> This came up while looking at the ExternallyProvisioned →
> Provisioned lifecycle boundary and related inspection/cleaning
> behaviour.
>
> Optional context for the wider runtime question I’m testing:
> https://github.com/hybridops-tech/hybridops-core/issues/269
> <https://github.com/hybridops-tech/hybridops-core/issues/269>
>
> A short view is more than enough.
>
> Best,
> Jeleel
>
> --
> You received this message because you are subscribed to the
> Google Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to metal3-dev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/
> metal3-dev/a8882d58-f533-45bb-
> groups.google.com/d/msgid/metal3-dev/a8882d58-f533-45bb-
> a91e-1599e0788e3bn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
>
>
>
> --
>
> Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
> Managing Directors: Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty
>
> You received this message because you are subscribed to the Google
> Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> dev+uns...@googlegroups.com>.
> groups.google.com/d/msgid/metal3-dev/0e175cbd-b00c-4290-918e-
> b2f3734aea2dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jeleel Muibi
The CAPI example is exactly the distinction I was trying to get at. Metal3/Ironic can be finished with provisioning while the wider user-requested outcome is still not complete.
So the outer check should not replace or reinterpret Metal3 state. It should use that state as one input, then wait for whatever proves the provisioned host is actually ready for its intended role.
That gives me a much clearer boundary. Thanks again.