Open Stack

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160801/fb417836/attachment.html>