Implement an Unmanaged (discovered) state (2)#569
Implement an Unmanaged (discovered) state (2)#569metal3-io-bot merged 6 commits intometal3-io:masterfrom
Conversation
|
/test-integration |
|
@dhellmann: GitHub didn't allow me to request PR reviews from the following users: n1r1. Note that only metal3-io members and repo collaborators can review this PR, and authors cannot review their own PRs. |
|
copying the comments from previous PR:
Yes. CAPx clients and downstream in OCP the UI might need some changes as well (e.g. gray out the reboot button if host has no BMC details) |
|
/test-integration |
|
yum mirror access failed /test-integration |
|
Since this is technically an API change and I keep asking people to write up docs for those, I've put metal3-io/metal3-docs#120 up for review. |
Define a new state for newly-created Hosts with no BMC details. We need the state definition so we can add it to CAPM3 so that does not break when metal3-io#569 merges. See metal3-io/metal3-docs#120 for more details.
|
This will need to be rebased on top of #571 |
d76a168 to
ecf6f93
Compare
This state isn't actually implemented in the code, so before we implement it rename it to "Unmanaged". This reflects the fact that what this state really means is that the Host has been created without attempting to provide credentials. That may have transpired through a discovery process or some other mechanism.
Bring the code into line with the state machine documentation, which says that once the Host is reconciled it will immediately move into one of the states (registering or unmanaged) and not remain with an empty provisioning state. Since the Unmanaged state has not been implemented yet, move unconditionally to Registering. Previously, we waited until the the BMC credentials had at least once been deemed worthy of trying (present, correctly formatted) before the Host would move to the Registering state.
Newly-created Hosts enter the Unmanaged state if no BMC details are provided in the resource Spec. As soon as details are provided - regardless of whether they are complete or correctly formatter - the Host will return to the Registering state. Even if all of the details are later removed, the Host will not return to the Unmanaged state. This is in line with how this state is documented in the state machine diagram, but it was never previously implemented.
When a host is discovered or otherwise created without any BMC data, it now goes into an Unmanaged state, in which buildAndValidateBMCCredentials() is not called. Once a host leaves the unmanaged state (i.e. the BMC address and/or credentials have been supplied at least once), any time the BMC address and/or credentials are missing it is due to a configuration error, not to having newly-discovered a host. Since the unmanaged state handles newly-discovered hosts, in the error handling for buildAndValidateBMCCredentials we can now flag an error if any of the data is missing. This prevents transitions like a Host going back into a "discovered" operational status despite having been provisioned already before the credentials were removed. That should be, and now is, treated as an error.
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
ecf6f93 to
d5b337b
Compare
|
/test-integration |
|
Rebased after #571 merged |
|
/hold we need to merge metal3-io/cluster-api-provider-metal3#108 and metal3-io/cluster-api-provider-metal3#109 before this |
|
/test-integration |
|
/hold clear This is ready for review and merging. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhellmann, zaneb The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold cancel |
|
/lgtm |
If no BMC credentials are provided, move the host to a new Unmanaged
state and change the operational status to discovered, rather than
remaining without a provisioning state and in an operational error.
This has always been envisaged in the state machine diagram (with the name
Discovered rather than Unmanaged), but was not previously implemented.
This is a rebased version of #563