Comment 5 for bug 2028866

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ironic (stable/2023.1)

Reviewed: https://review.opendev.org/c/openstack/ironic/+/895039
Committed: https://opendev.org/openstack/ironic/commit/58251eb3730e4d49322db3e5c7ddc169fc9539b0
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit 58251eb3730e4d49322db3e5c7ddc169fc9539b0
Author: Julia Kreger <email address hidden>
Date: Thu Jul 27 10:01:31 2023 -0700

    DB: Select upon delete for allocations

    When an allocation has been created, it is still being created
    in the background. The client may request deletion of the
    allocation *prior* to the creation of the allocation is entirely
    completed. That is fine, but the challenge is we may encounter a
    locked row if we're asked to delete while in process.

    So, we'll query with with_for_update[0] which should be held until
    the lock is released, which is only released when the original
    locking transaction closes out[1][2].

    [0]: https://docs.sqlalchemy.org/en/14/core/selectable.html#sqlalchemy.sql.expression.GenerativeSelect.with_for_update
    [1]: https://dev.mysql.com/doc/refman/5.7/en/select.html
    [2]: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html

    Change-Id: I0b68f054c951655b01f0cd776feb5a8c768471ab
    Closes-Bug: #2028866
    (cherry picked from commit 6ac0bdab1de8219fed419a838663aa82973e93e9)