Comment 13 for bug 1706750

Reviewed: https://review.openstack.org/529169
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d4c41071645d0c25485d93886fbc09ca671ea18b
Submitter: Zuul
Branch: master

commit d4c41071645d0c25485d93886fbc09ca671ea18b
Author: Ihar Hrachyshka <email address hidden>
Date: Tue Dec 19 13:54:02 2017 -0800

    ipam: don't commit IPAllocation while IpamAllocation is rolled back

    Don't mix old and new session management styles. Mixing them is not
    guaranteed to work. The method is not switched to new enginefacade yet,
    so stick to the old style. Since OVO create() method already opens a
    nested transaction, do nothing in IPAM layer.

    This change fixes an issue where sometimes, whenever
    add_auto_addrs_on_network_ports raises a retriable exception like
    StaleDataError, corresponding IPAllocation is still persisted in the
    database without being rolled back and without the corresponding
    IpamAllocation model persisted. Later, this situation may break port and
    network deletion for resources affected by the issue, failing with the
    following error:

    Unable to find IP address 2003::f816:3eff:fed2:5006 on subnet
    eed623f4-cbad-488c-b230-7f4a8b1514eb

    It happens because whenever writer.using context manager exits, and it's
    top level manager, it commits the changes to database. Since
    writer.using doesn't know that it's being executed in scope of the old
    facade .begin() call, it doesn't postpone commitment as needed.

    The bug was introduced in Pike as part of the switch to the new
    enginefacade (that was never fully completed), specifically by:
    I50be115ea69f805b48b02aebe4259ec2c839830e

    For existing setups that already have IPAllocation objects without
    IpamAllocation counterparts, the solution is to remove those
    dangling IPAllocations manually from the database. (That's of course
    assuming they use Neutron DB IPAM plugin in the first place.)

    Note: If we ever decide to remove nested transactions from OVO base
    layer, we may need to revisit this code to keep ignore-on-failure
    semantics.

    Change-Id: Ic9e146f51d9a120011892828d3a67b0630f4c5ce
    Closes-Bug: #1706750