Open Stack

>We still want the exception to rollback the entire API operation and
stopping it with a nested operation I think would mess that up.

Well I think you would want to start a nested transaction, capture the
duplicate, call the ipam delete methods, then throw a retryrequest. The
exception will still trigger a rollback of the entire operation.


>Second, I've been throwing around the idea of not sharing the session with
the IPAM driver.

If the IPAM driver does not have access to the session, it can't see any of
the uncommitted data. Would that be a problem? In particular, doesn't the
IPAM driver's DB table have foreign key constraints with the data waiting
to be committed in the other session? I'm hesitant to take this approach
because it means other (if the in-tree doesn't already) IPAM drivers cannot
have any relational integrity with the objects in question.

A related question is, why does the in-tree IPAM driver have to do anything
at all on a rollback? It currently does share a session which is
automatically going to rollback all of it's DB operations for it. If it's
because the driver cannot distinguish a delete call from a rollback and a
normal delete, I suggest we change the delete call to pass a flag
indicating that it's for a rollback. That would allow any DB-based drivers
to just do nothing at this step.



On Mon, Aug 1, 2016 at 12:28 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> Hi all,
>
> Last Thursday, I spent the afternoon looking in to a bug with pluggable
> IPAM [1] which is preventing me from deciding to pull the trigger on
> finally switching from the old non-pluggable reference implementation. I'd
> *really* like to get this in shape for Newton but time is running out.
>
> I've written a unit test [2] which manages to tickle the issue with
> rollback. It is a bit convoluted but basically it hijacks the call to
> _store_ip_allocation to reliably simulate another process racing for the
> same address and writes an allocation to the DB for the same ip address it
> is trying to allocate. The unit test also has to have something to rollback
> so it allocates two fixed ips to the port. The first one succeeds and then
> the second one fails (hence the initial call to "skip_one").
>
> I think the issue stems from the fact that the reference driver for
> pluggable IPAM shares the session with the rest of the API call. Writing
> the allocation fails with a DBDuplicate in the main part of the API call
> but then tries to rollback. Rollback fails because the session has already
> been "broken" by the duplicate exception.
>
> To fix this, I've thrown around a couple of ideas. First, I thought of
> maybe adding nested transactions in key places to isolate the part that is
> going to break. I could continue to pursue this but it is as
> straight-forward as it first seemed to me. We still want the exception to
> rollback the entire API operation and stopping it with a nested operation I
> think would mess that up.
>
> Second, I've been throwing around the idea of not sharing the session with
> the IPAM driver. I recall we had some discussion about this a long time ago
> but I cannot remember the conclusion. To me, it seems that the IPAM driver
> should not be sharing a session with the main API call. This would put it
> on par with other external IPAM drivers which would certainly not be
> sharing a DB context, let alone the DB itself, with the neutron API.
>
> Do you have any thoughts on this?
>
> Carl
>
> [1] https://bugs.launchpad.net/neutron/+bug/1603162
> [2] https://review.openstack.org/#/c/348956/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160801/b7ba234f/attachment.html>