[openstack-dev] [Neutron] Calling a controller from within a session in the plugin
sorlando at nicira.com
Wed Dec 11 10:34:06 UTC 2013
I think there's little to add to what Aaron said.
This mechanism might end up generating long-running sql transactions which
have a detrimental effect on the availability of connections in the pool as
well as the threat of the deadlock with eventlet.
We are progressively removing all the controller API calls nested within DB
transactions from the plugin we maintain; this is not easy as it often
requires to override methods from the database base class and mixins,
however I think ML2 pre/post commit architecture should make this better.
On 5 December 2013 00:56, Aaron Rosen <aaronorosen at gmail.com> wrote:
> In my experience doing any kind of http request inside a of a db
> transaction kills performance vastly (and can lead to situations where
> deadlock often occurs due to eventlet+sqlalchemly). This topic also was
> recently discussed here:
> On Wed, Dec 4, 2013 at 9:15 AM, Mohammad Banikazemi <mb at us.ibm.com> wrote:
>> Have a question regarding calling an external SDN controller in a plugin.
>> The ML2 model brings up the fact that it is preferred not to call an
>> external controller within a database session by splitting up each call
>> into two calls: *_precommit and *_postcommit. Makes sense.
>> Looking at the existing monolithic plugins, I see some plugins that do
>> not follow this approach and have the call to the controller from within a
>> session. The obvious benefit of this approach would be a simpler cleanup
>> code segment for cases where the call to controller fails. So my question
>> is whether it is still OK to use this simpler approach in monolithic
>> plugins. As we move to the ML2 model, we will be using the ML2 approach but
>> in the meantime, we leave the option of calling the controller within a
>> session as an OK option. Would that be reasonable?
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev