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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
