Auto-created consumer record not cleaned up after failed allocation

[Jay Pipes]

If a call to ``PUT /allocations/{consumer}`` fails, for example with a 409 Conflict due to a resource provider or inventory being concurrently updated, the consumer record that is auto-created in the handler before calling AllocationList.create_all() is not being cleaned up properly.

This results in situations like bug #1778591 where a caller can get seriously confused when attempting to retry creating allocations for a consumer, since the retry will now expect a non-null consumer generation when the API is called with microversion 1.28+

The solution is simple: clean up the auto-created consumer record if a failure occurs when creating allocations for a *new* consumer.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/579654

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Jay Pipes (<email address hidden>) on branch: master
Review: https://review.openstack.org/579654
Reason: We decided to delete consumers when no allocations, so this is no longer a valid patch.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/579921
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c64198182646e0f264951dc24ed3ef98a297e888
Submitter: Zuul
Branch: master

commit c64198182646e0f264951dc24ed3ef98a297e888
Author: Jay Pipes <email address hidden>
Date: Tue Jul 3 12:48:34 2018 -0400

    placement: delete auto-created consumers on fail

    When we fail to create allocations for new consumers (either when
    issuing a PUT /allocations/{new_consumer_uuid} or a POST /allocations
    where the payload includes a new consumer UUID), we need to ensure that
    we delete the Consumer object and underlying record in the consumers
    table that gets auto-created before calling AllocationList.create_all().

    This auto-created consumer record is what is used to compare things like
    consumer generation in later calls to PUT|POST /allocations, and this
    phantom consumer record was causing confusion when normal retries (for
    things like 409 Conflict due to concurrent provider or inventory
    updates) would be rejected stating that the expected consumer generation
    was 0 and not null (null being the sentinel that indicates the caller is
    expecting the consumer is a new consumer).

    Change-Id: If37ef318bd5482a2d19928002c6f1fa24932946f
    Closes-bug: #1779725
    Closes-bug: #1778576

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 18.0.0.0b3 development milestone.