On 3/23/15, 11:03 AM, "Salvatore Orlando" <sorla...@nicira.com<mailto:sorla...@nicira.com>> wrote:
Whether is a big deal or a failure it depends on one's expectation. If the expectation is to enable external IPAM backends, then I agree that this is not a big deal. However, my expectation (and I hope I'm not the only one), was to disentangle IPAM logic from the API request processing code. In this way 3rd party backend transactions would have been executed independently of the database operation for processing the API request. Also, this would have enabled us to integrate tools like taskflow (I think Pavel looked into that). And most importantly avoid long database transactions which include remote calls as well.\ I agree this is a worthy goal we should look to achieve in Liberty. It will require a lot more refactoring but should clean things up nicely. However, this is not achievable - and mostly for an oversight on our side. So we should welcome passing down the context to the driver, with the goal of removing it in the next release. I think it will be fair to assume the interface "experimental" for this release cycle - and "stable" for the next one. Makes sense to me. The issue is not really with mysql connector but more in its interaction with eventlet. This is something that will eventually (hopefully soon) be sorted within oslo_db. However, generally speaking it is better to avoid long-standing database transactions. However, we've provided enough reasons for which we'd need, at least for this release, push down the database session to the IPAM driver. So it's now up to reviewers to decide whether this is acceptable or not. Ok. The technical debt aspect of adding a session to the driver is simply due to the fact that we'll need to have a follow-up action to remove it. Such follow up action will imply some more refactoring in the db base class, possibly removing some of the code Pavel is introducing and moving it into an appropriate IPAM integration module. This will be the additional technical debt. On the other hand, if the developers working on IPAM agree that it is ok to keep passing down the session to the IPAM driver as a permanent solution, then we have less technical debt to deal with (and this would be the one we anticipated because for Kilo Neutron should be able to run with and without the IPAM driver) I see your point, it creates a bit more work in the next cycle. John
__________________________________________________________________________ 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
