On 3/20/15, 8:31 PM, "Salvatore Orlando" <[email protected]<mailto:[email protected]>> wrote:
As the IPAM driver is called in NeutronDbPluginV2, this call happens while another transaction is typically in progress. Initiating a separate session within the IPAM driver causes the outer transaction to fail. I do not think there is a lot we can do about this at the moment, unless we agree on a more pervasive refactoring: This is essentially what is described in the "Refactoring" section of the spec [1] (see the third paragraph in that section specifically). The original expectation (as you say) was that we would be able to achieve this by only changing the DB plugin, but this looks to not be feasible at this point given the way sessions are handled in the subclasses. Otherwise, we'd just made the IPAM driver session aware. This implies changes to the Pool and Subnet interface to accept an optional session parameter. The above works and is probably quicker from an implementation perspective. However, doing so somehow represents a failure of the pluggable IPAM effort as total separation between IPAM and API operation processing was one of our goals. Actually, I don't see this as a big deal or a failure. In fact, it may be quite common and useful for a given driver to store some state in its own tables (like the reference driver is doing). The primary goal is to enable alternate IPAM implementations, whether external or completely local. That goal is still achieved even with this change. So, I don't see a big problem with the IPAM driver being session-aware. Also, for drivers with a remote backend, remote calls will be made within a DB transaction, which is another thing we wanted to avoid. This is more of a concern, due to the issue with the mysql connector. I guess I'd like to understand better what that issue is and how we may resolve it, since it is a source of pain not just for IPAM. And finally, there is the third option. I know IPAM contributors do not even want to hear it... but the third option is to enjoy 6 more months to come up with a better implementation which does not add any technical debt. In Kilo from the IPAM side we're already introducing subnet pools, so it won't be a total failure! I think we can still handle the primary use case without adding technical debt. We had hoped to *re-pay* more technical debt with the refactor than we are able to achieve, but I don't see any additional debt by making the driver session-aware. John [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
