unable to abort wait for call-back state

[George Shuklin]

If node is in the wait call-back state there is no way for administrator to abort this operation. I believe it should be, because administrator should be able to cancel any pending operations on the node.

Steps to reproduce:

Put node to wait call-back state.

Call:
ironic --ironic-api-version 1.22 node-set-maintenance $uuid on
ironic --ironic-api-version 1.22 node-set-provision-state a93c9183-c057-46e4-a314-2e6982523c4d abort

Expected behavior: node in some kind of fail state which can be moved to manage mode later.

Actual behavior:
The requested action "abort" can not be performed on node "a93c9183-c057-46e4-a314-2e6982523c4d" while it is in state "wait call-back". (HTTP 400)

version: newton

[Kyrylo Romanenko (kromanenko)]

Please check possible ways of state changes from `wait call-back` state: http://docs.openstack.org/developer/ironic/_images/states.svg

Also please add to bug report which driver is used for your node, it can matter.

[Kyrylo Romanenko (kromanenko)]

BTW, can you delete node from this state?

[George Shuklin (george-shuklin)]

I used nova delete command and it has made node 'cleaning'-> 'available'. I think there was a 'delete' state too, but I'm not sure.

On this image (http://docs.openstack.org/developer/ironic/_images/states.svg) there is no API way to abort wait call-back state for deployment.

deployment -> wait call-back -> [no abort via API]

[Kyrylo Romanenko (kromanenko)]

Thus it is expected that aborting is not applicable from `wait call-back` state. And ironic returns an error message.

[George Shuklin (george-shuklin)]

Yes, but my bugreport is about a problem for administrators (operators). They do expect that they can abort deploy at any stage.

I understand that current implementation is according to node states chart, but I think that chart itself should be changed.

I don't see any reason why out of all prolonged states, only 'wait for call-back in deployment' can't be aborted. Same wait in 'clean wait' may be aborted, but 'deploying' can't.

P.S. I've looked closely to the chart. I believe both 'wait of call-back' and 'deploying' stages should be abortable.

[Dmitry Tantsur (divius)]

Have you tried

 ironic node-set-provision-state NODE deleted

?

[George Shuklin (george-shuklin)]

I didn't, and now this instance is gone. May be 'deleted' will work. But why 'abort' does not supported? I think any operation should be abortable by administrator. Nova has special 'nova reset-state' command for this which simply sets 'ERROR' on instance regardless of it current state.

[Adam Vinsh (adam-vinsh)]

Just wanted to add this here to help others that hit this. I too was stuck staring at a node stuck in wait call-back and found that Dimitrys advice was the only way:

# ironic node-list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| 88c67dd5-6e96-4a59-b361-2732181bc528 | bmnode | 38142793-dd8b-456c-9301-2c2d5198e4c6 | power on | wait call-back | False |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+

# ironic node-list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| 88c67dd5-6e96-4a59-b361-2732181bc528 | bmnode | 38142793-dd8b-456c-9301-2c2d5198e4c6 | power on | wait call-back | False |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+

# ironic --ironic-api-version 1.22 node-set-provision-state bmnode deleted

# ironic node-list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| 88c67dd5-6e96-4a59-b361-2732181bc528 | bmnode | 38142793-dd8b-456c-9301-2c2d5198e4c6 | power on | deleting | False |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+

# ironic --ironic-api-version 1.22 node-set-provision-state bmnode manage

# ironic node-list
+--------------------------------------+--------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+---------------+-------------+--------------------+-------------+
| 88c67dd5-6e96-4a59-b361-2732181bc528 | bmnode | None | power off | manageable | False |
+--------------------------------------+--------+---------------+-------------+--------------------+-------------+
# ironic --ironic-api-version 1.22 node-set-provision-state bmnode provide

[Michael Turek (mjturek)]

So can confirm that 'abort' still behaves this way. It's unclear why 'deleted' is the way to go rather than 'abort'. I would expect that aborting a deployment would start the cleaning process.