I think we need to revisit when we should be raising exception.Conflict. This causes an HTTP 409 status in the response. In an IRC chat with Lucas about it [1], Lucas mentioned "usually CONFLICT means another operation is in progress so the request conflicted".
I've encountered two cases recently where we probably should not be returning it:
- when a node is destroyed (deleted) [2], it makes sense for NodeLocked, but not if an instance is associated with a node or the node is in an unexpected state
- if a node is created (or updated) with the name of an existing node, the DuplicateName exception is percolated up.
I think we need to:
1. understand what is a Conflict (to the user) and what isn't
2. find out where we're 'abusing' it and make the appropriate changes
3. this is unclear to me -- if we change the HTTP status, it could break existing deployments that eg, are keying on 'HTTP 409'. How do we deal with this? (Maybe a new microversion?)
For example, using python-ironicclient, if I try to create a node with the name of an existing node, the client handles conflicts by retrying 6 times (so issues the request 7 times) to the server, before failing.
$ ironic node-create -d fake_ipmitool -n foo
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+
| uuid | 20374cd3-e191-4685-910f-d117121643c0 |
| driver_info | {} |
| extra | {} |
| driver | fake_ipmitool |
| chassis_uuid | |
| properties | {} |
| name | foo |
+--------------+--------------------------------------+
$ ironic node-create -d fake_ipmitool -n foo
A node with name foo already exists. (HTTP 409)
[1] around 2015-06-02T14:59:53, http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-06-02.log
[2] https://github.com/openstack/ironic/blob/b0840884a14f9efdee89c7c45e77d1d602e9616f/ironic/conductor/manager.py#L1262
We discussed this a bit at our weekly meeting on July 13, starting at 17:23:54:
http://