Generating UUIDs on the server can lead to duplicates

[aeva black]

Resource creation is done via "POST /v1/{type}" with a body containing some details about the resource. The resource identifier is generated on the server and returned to the client.

There are two potential problems:

If a POST request is received twice (eg, due to a network hiccup or a misconfigured proxy), multiple resources will be created instead of one, but the client is only expecting one response.

If a POST response is lost (eg, due to a network hiccup or the API service being killed), a resource will be created and the client will try again, generating a second resource.

In both cases, there are resources created for which the client does not receive a resource identifier.

Alternately, if the resource has a natural primary key (eg, a Port's MAC address), the client may get unexpected duplicate errors and need to search to find the identifier for the resource it was trying to create.

A solution to this is to require clients to generate the resource identifier (eg, UUID) and then "PUT /v1/{type}/{uuid}". This would make resource-creation-requests idempotent and solve the above problems.

[Mark McLoughlin (markmc)]

POSTs should not be assumed to be idempotent, so proxies shouldn't cache them by default

If true, your logic here would apply equally to all REST APIs and we'd never have non-idempotent, resource-creating POSTs

[aeva black (tenbrae)]

A similar scenario: http connection is interrupted (timeout? API service restart? etc) but the resource is created by the service on the far end of the internal RPC bus. The client has no resource identifier to issue a GET to determine if it was successful or not, so they will re-issue POST and generate a duplicate resource -- or worse, if the resource contains a natural primary key, they'll unexpectedly get a duplicate error and have to search for the resource to find its identifier.

If clients were required to generate the resource identifier when creating a resource, this would not be a problem.

[aeva black (tenbrae)]

Changing priority to low because this doesn't prevent any features from working. A client could work around it as described in comment #2.

[aeva black (tenbrae)]

I'll update the bug description to be more general.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/130228

[Vladyslav Drok (vdrok)]

Bug can be closed as discussed in meeting: http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-12-01-17.02.log.html

[Lucas Alvares Gomes (lucasagomes)]

The proposed solution means to pass a UUID when creating/updating a node. But it's already supported in our API when doing POST too.

[stack@localhost devstack]$ ironic node-create -d fake -u 883c4e33-8aa3-43d1-b887-850476df3aa0
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+
| uuid | 883c4e33-8aa3-43d1-b887-850476df3aa0 |
| driver_info | {} |
| extra | {} |
| driver | fake |
| chassis_uuid | |
| properties | {} |
+--------------+--------------------------------------+
[stack@localhost devstack]$ ironic node-create -d fake -u 883c4e33-8aa3-43d1-b887-850476df3aa0
A node with UUID 883c4e33-8aa3-43d1-b887-850476df3aa0 already exists. (HTTP 409)

I don't see the reason we should add PUT support in our API for that, for two reasons:

1 - We have readonly fields which makes PUT a bit odd, since those are not updatable.

2 - It does duplicate functionaly in our API.

[John Stafford (john-stafford)]

I am closing this ticket as "won't fix" based on the notes above.