As per the state machine specification, there should not be a transition from CLEANFAIL -> CLEANING directly, and so the REST API is correct. That the internal state machine represents this transition is a bug and should be fixed in Liberty, but there's no need to back port it as this is not exposed in the Kilo API. I have removed that tag, and will close this bug. I have opened a new one here: https://bugs.launchpad.net/ironic/+bug/1446758
CLEANING
Nodes in the CLEANING state are being scrubbed in preparation to being made AVAILABLE. Good candidates for CLEANING tasks include:
[snip...]
Management of CLEANING tasks should be handled in the same fashion as ZAPPING tasks.
ZAPFAIL
Nodes that transition into ZAPFAIL will automatically enter maintenance mode, as failure to ZAP a machine usually indicates a hardware failure or something else that requires remote hands to fix.
As per the state machine specification, there should not be a transition from CLEANFAIL -> CLEANING directly, and so the REST API is correct. That the internal state machine represents this transition is a bug and should be fixed in Liberty, but there's no need to back port it as this is not exposed in the Kilo API. I have removed that tag, and will close this bug. I have opened a new one here: /bugs.launchpad .net/ironic/ +bug/1446758
https:/
For reference, I'll quote the spec here as well. specs.openstack .org/openstack/ ironic- specs/specs/ kilo/new- ironic- state-machine. html#proposed- change
http://
CLEANING
Nodes in the CLEANING state are being scrubbed in preparation to being made AVAILABLE. Good candidates for CLEANING tasks include:
[snip...]
Management of CLEANING tasks should be handled in the same fashion as ZAPPING tasks.
ZAPFAIL
Nodes that transition into ZAPFAIL will automatically enter maintenance mode, as failure to ZAP a machine usually indicates a hardware failure or something else that requires remote hands to fix.