<div dir="ltr">><span style="font-size:12.8px">We still want the exception to rollback the entire API operation and stopping it with a nested operation I think would mess that up.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">Second, I've been throwing around the idea of not sharing the session with the IPAM driver.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><br></div><div>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.</div><div><br></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 12:28 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Hi all,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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").</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Do you have any thoughts on this?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Carl</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">[1] <a href="https://bugs.launchpad.net/neutron/+bug/1603162" target="_blank">https://bugs.launchpad.net/neutron/+bug/1603162</a></div><div style="font-size:12.8px">[2] <a href="https://review.openstack.org/#/c/348956/" target="_blank">https://review.openstack.org/#/c/348956/</a></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>