Bug 1917484: Don't adopt after clean failure during deprovisioning#121
Bug 1917484: Don't adopt after clean failure during deprovisioning#121zaneb wants to merge 1 commit intoopenshift:masterfrom
Conversation
During deprovisioning of a Host, if 'deleting' (i.e. deprovisioning) the node succeeds (i.e. it doesn't go to the Error state) but the automated cleaning that follows fails, the only way to recover is to return the node to the manageable state. Previously, once in the manageable state we would attempt adoption on the node so that we could deprovision again. However, in the course of 'deleting' the node, the image information is cleared from it so it cannot be adopted again. (Adoption continues to be the right thing to do if the node has just been re-registered due to the Ironic database being recreated, and in that case the image information is present since it gets added during the initial registration.) To work around this, don't attempt to adopt during the Deprovisioning state if the node is manageable and the image data is not present. Handle the manageable state in Deprovision() by declaring the deprovisioning complete. A node in the manageable state cannot be re-provisioned without first being cleaned - it must go through cleaning to reach the available state before it can be provisioned. Provisioning already handles nodes in the manageable state, as this is how they begin after the initial inspection of the host before the first provisioning (which does the initial cleaning). (cherry picked from commit ba38688)
openshift-ci-robot
added
the
bugzilla/severity-high
|
@zaneb: This pull request references Bugzilla bug 1917484, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
DetailsIn response to this:
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/test-infra repository. |
openshift-ci-robot
added
the
bugzilla/valid-bug
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
openshift-ci-robot
added
the
approved
|
@zaneb: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
This seems to depend on metal3-io@0e1acfe which is part of metal3-io#761 |
|
Closing in favour of #122 |
|
@honza: Closed this PR. DetailsIn response to this:
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/test-infra repository. |
|
@zaneb: This pull request references Bugzilla bug 1917484. The bug has been updated to no longer refer to the pull request using the external bug tracker. DetailsIn response to this:
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/test-infra repository. |
3 participants
During deprovisioning of a Host, if 'deleting' (i.e. deprovisioning) the
node succeeds (i.e. it doesn't go to the Error state) but the automated
cleaning that follows fails, the only way to recover is to return the
node to the manageable state.
Previously, once in the manageable state we would attempt adoption on
the node so that we could deprovision again. However, in the course of
'deleting' the node, the image information is cleared from it so it
cannot be adopted again. (Adoption continues to be the right thing to do
if the node has just been re-registered due to the Ironic database being
recreated, and in that case the image information is present since it
gets added during the initial registration.)
To work around this, don't attempt to adopt during the Deprovisioning
state if the node is manageable and the image data is not present.
Handle the manageable state in Deprovision() by declaring the
deprovisioning complete.
A node in the manageable state cannot be re-provisioned without first
being cleaned - it must go through cleaning to reach the available state
before it can be provisioned. Provisioning already handles nodes in the
manageable state, as this is how they begin after the initial inspection
of the host before the first provisioning (which does the initial
cleaning).
Backport of metal3-io#772