describe unmanaged state for hosts

[dhellmann]

Related to metal3-io/baremetal-operator#569

Co-Authored-By: Zane Bitter zbitter@redhat.com

[dhellmann]

Based on @n1r1's reviews of metal3-io/baremetal-operator#569 I thought I had better put together a document explaining the API change there.

/cc @n1r1 @zaneb @maelk @kirankt @honza @stbenjam

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhellmann

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [dhellmann]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kirankt]

Should we also include cluster-api-provider-baremetal here now that the projects differ significantly.

[dhellmann]

I left that out because it's a downstream concern, but the changes would essentially be the same.

[n1r1]

Looks good to me. Some minor comments:

1. Even if it's obvious for some users, I think we should mention explicitly that BMO won't be able to apply the desired state for unmanaged hosts. For example, any change to Online won't have any effect until BMC credentials are supplied.
2. The change in consumers is not only where they look at the host state. It's also where they are not. For example, downstream in OCP, there's remediation code which assumes that any host has power management. So I think that any consumer who's trying to change spec.Online is potentially affected by this change

[dhellmann]

Looks good to me. Some minor comments:

1. Even if it's obvious for some users, I think we should mention explicitly that BMO won't be able to apply the desired state for unmanaged hosts. For example, any change to Online won't have any effect until BMC credentials are supplied.

I think that's covered by https://github.com/metal3-io/baremetal-operator/pull/569/files#diff-0f426376b964e609c5c4618eb8bed3b2R372

2. The change in consumers is not only where they look at the host state. It's also where they are not. For example, downstream in OCP, there's remediation code which assumes that any host has power management. So I think that any consumer who's trying to change spec.Online is potentially affected by this change

I don't think the remediation code should change to behave differently when credentials are not present. That expects the caller to understand too much about how the baremetal operator works with hosts.

Even with credentials present, they might be wrong, and therefore the remediation would fail. The BMC might be frozen, and so remediation would fail. The BMC might be disconnected, and so remediation would fail. The calling code needs to deal with all of those cases. It should be able to ask for a reboot and then if that reboot does not happen for any reason it should be able to make a new decision about what to do.

[maelk]

/lgtm