On Tue, Aug 2, 2016 at 6:55 PM, Carl Baldwin <carl at ecbaldwin.net> wrote: > On Aug 2, 2016 6:52 PM, "Kevin Benton" <kevin at benton.pub> wrote: > > If we decide to just fix the exception handler inside of ipam itself for > rollbacks (which would be a quick fix), I would be okay with that but we > need to be clear that any driver depending on that alone for state > synchronization is in a very dangerous position of becoming inconsistent > (i.e. I want something to point people to if we get bug reports saying that > the delete call wasn't made when the port failed to create). > > I think we could fix it in steps. I do think that both issues are worth > fixing and will pursue them both. I'll file a bugs. > After some discussion in IRC [2], I think I have a plan. The short term fix is to stop calling rollback for the in-tree driver. Since it uses the same DB session as Neutron, its changes will be rolled back regardless. I implemented that in the context of the original patch that I linked early in this thread [1]. I also cleaned up the unit test *a lot* now that I had a little time to see what it really needed to do. I think that can merge now to fix rollback for the in-tree driver (which would be the only one broken in this way anyway). This still leaves the fact that IPAM rollback is really pretty broken for other drivers. This isn't new in Newton but now we understand better how badly it is broken. I've filed a bug about that [3]. Carl [1] https://review.openstack.org/#/c/348956 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-08-03.log.html#t2016-08-03T18:08:58 [3] https://bugs.launchpad.net/neutron/+bug/1610483 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160805/32885033/attachment.html>