<div dir="ltr">There are few examples of ML2 mechanism drivers. You can look at Arista ML2 driver. We deal with the DB synchronization as well back-end<div>provisioning. We deal with back-end failures and roll-backs as well synchronization between Neutron and back-end. </div>
<div><br></div><div style>best of luck</div><div style>-Sukhdev</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 5:27 PM, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/18/2013 05:21 PM, Edgar Magana wrote:<br>
> Hi All,<br>
><br>
> Thank you everybody for your input. It is clear that any solution requires<br>
> changes at the plugin level (we were trying to avoid that). So, I am<br>
> wondering if a re-factor of this code is needed of not (maybe not).<br>
> The ML2 solution is probably the best alternative right now, so we may go<br>
> for it.<br>
<br>
</div>Could be a good time to consider converting the plugin to an ML2<br>
MechanismDriver. I'm happy to help work through the details of that if<br>
your are interested.<br>
<br>
-Bob<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Any extra input is welcome!<br>
><br>
> Thanks,<br>
><br>
> Edgar<br>
><br>
> On 11/18/13 12:55 PM, "Robert Kukura" <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>> wrote:<br>
><br>
>> On 11/18/2013 03:25 PM, Edgar Magana wrote:<br>
>>> Developers,<br>
>>><br>
>>> This topic has been discussed before but I do not remember if we have a<br>
>>> good solution or not.<br>
>><br>
>> The ML2 plugin addresses this by calling each MechanismDriver twice. The<br>
>> create_network_precommit() method is called as part of the DB<br>
>> transaction, and the create_network_postcommit() method is called after<br>
>> the transaction has been committed. Interactions with devices or<br>
>> controllers are done in the postcommit methods. If the postcommit method<br>
>> raises an exception, the plugin deletes that partially-created resource<br>
>> and returns the exception to the client. You might consider a similar<br>
>> approach in your plugin.<br>
>><br>
>> -Bob<br>
>><br>
>>> Basically, if concurrent API calls are sent to Neutron, all of them are<br>
>>> sent to the plug-in level where two actions have to be made:<br>
>>><br>
>>> 1. DB transaction No just for data persistence but also to collect the<br>
>>> information needed for the next action<br>
>>> 2. Plug-in back-end implementation In our case is a call to the python<br>
>>> library than consequentially calls PLUMgrid REST GW (soon SAL)<br>
>>><br>
>>> For instance:<br>
>>><br>
>>> def create_port(self, context, port):<br>
>>> with context.session.begin(subtransactions=True):<br>
>>> # Plugin DB - Port Create and Return port<br>
>>> port_db = super(NeutronPluginPLUMgridV2,<br>
>>> self).create_port(context,<br>
>>><br>
>>> port)<br>
>>> device_id = port_db["device_id"]<br>
>>> if port_db["device_owner"] == "network:router_gateway":<br>
>>> router_db = self._get_router(context, device_id)<br>
>>> else:<br>
>>> router_db = None<br>
>>> try:<br>
>>> LOG.debug(_("PLUMgrid Library: create_port() called"))<br>
>>> # Back-end implementation<br>
>>> self._plumlib.create_port(port_db, router_db)<br>
>>> except Exception:<br>
>>> Š<br>
>>><br>
>>> The way we have implemented at the plugin-level in Havana (even in<br>
>>> Grizzly) is that both action are wrapped in the same "transaction" which<br>
>>> automatically rolls back any operation done to its original state<br>
>>> protecting mostly the DB of having any inconsistency state or left over<br>
>>> data if the back-end part fails.=.<br>
>>> The problem that we are experiencing is when concurrent calls to the<br>
>>> same API are sent, the number of operation at the plug-in back-end are<br>
>>> long enough to make the next concurrent API call to get stuck at the DB<br>
>>> transaction level, which creates a hung state for the Neutron Server to<br>
>>> the point that all concurrent API calls will fail.<br>
>>><br>
>>> This can be fixed if we include some "locking" system such as calling:<br>
>>><br>
>>> from neutron.common import utile<br>
>>> Š<br>
>>><br>
>>> @utils.synchronized('any-name', external=True)<br>
>>> def create_port(self, context, port):<br>
>>> Š<br>
>>><br>
>>> Obviously, this will create a serialization of all concurrent calls<br>
>>> which will ends up in having a really bad performance. Does anyone has a<br>
>>> better solution?<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Edgar<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>