<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Hi Mathieu,</div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"> Sorry I wasn't following the recent progress on ML2, and I was effectively missing the right abstractions of all MDs in my out of topic questions.</div>
<div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">If I understand correctly, there will be no priority between all MDs binding the same port, but an optional "port filter" could also be used so that the first responding MD matching the filter will assign itself.</div>
<div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Thanks for your answer.</div>
<div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Best Regards,</div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">
Racha</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 3:17 AM, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi racha,<br>
<br>
I don't think your topic has something to deal with Nader's topics.<br>
Please, create another topic, it would be easier to follow.<br>
FYI, robert kukura is currently refactoring the MD binding, please<br>
have a look here : <a href="https://bugs.launchpad.net/neutron/+bug/1276391" target="_blank">https://bugs.launchpad.net/neutron/+bug/1276391</a>. As<br>
i understand, there won't be priority between MD that can bind a same<br>
port. The first that will respond to the binding request will give its<br>
vif_type.<br>
<br>
Best,<br>
<br>
Mathieu<br>
<div><div class="h5"><br>
On Fri, Mar 14, 2014 at 8:14 PM, racha <<a href="mailto:benali@gmail.com">benali@gmail.com</a>> wrote:<br>
> Hi,<br>
> Is it possible (in the latest upstream) to partition the same<br>
> integration bridge "br-int" into multiple isolated partitions (in terms of<br>
> lvids ranges, patch ports, etc.) between OVS mechanism driver and ODL<br>
> mechanism driver? And then how can we pass some details to Neutron API (as<br>
> in the provider segmentation type/id/etc) so that ML2 assigns a mechanism<br>
> driver to the virtual network? The other alternative I guess is to create<br>
> another integration bridge managed by a different Neutron instance? Probably<br>
> I am missing something.<br>
><br>
> Best Regards,<br>
> Racha<br>
><br>
><br>
> On Fri, Mar 7, 2014 at 10:33 AM, Nader Lahouti <<a href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 1) Does it mean an interim solution is to have our own plugin (and have<br>
>> all the changes in it) and declare it as core_plugin instead of Ml2Plugin?<br>
>><br>
>> 2) The other issue as I mentioned before, is that the extension(s) is not<br>
>> showing up in the result, for instance when create_network is called<br>
>> [result = super(Ml2Plugin, self).create_network(context, network)], and as<br>
>> a result they cannot be used in the mechanism drivers when needed.<br>
>><br>
>> Looks like the process_extensions is disabled when fix for Bug 1201957<br>
>> committed and here is the change:<br>
>> Any idea why it is disabled?<br>
>><br>
>> ----------<br>
>> Avoid performing extra query for fetching port security binding<br>
>><br>
>> Bug 1201957<br>
>><br>
>><br>
>> Add a relationship performing eager load in Port and Network<br>
>><br>
>> models, thus preventing the 'extend' function from performing<br>
>><br>
>> an extra database query.<br>
>><br>
>> Also fixes a comment in securitygroups_db.py<br>
>><br>
>><br>
>> Change-Id: If0f0277191884aab4dcb1ee36826df7f7d66a8fa<br>
>><br>
>> master h.1<br>
>><br>
</div></div>>> ...<br>
<div class="HOEnZb"><div class="h5">>><br>
>> 2013.2<br>
>><br>
>> commit f581b2faf11b49852b0e1d6f2ddd8d19b8b69cdf 1 parent ca421e7<br>
>><br>
>> Salvatore Orlando salv-orlando authored 8 months ago<br>
>><br>
>><br>
>> 2 neutron/db/db_base_plugin_v2.py View<br>
>><br>
>> @@ -995,7 +995,7 @@ def create_network(self, context, network):<br>
>><br>
>> 995 'status': constants.NET_STATUS_ACTIVE}<br>
>><br>
>> 996 network = models_v2.Network(**args)<br>
>><br>
>> 997 context.session.add(network)<br>
>><br>
>> 998 - return self._make_network_dict(network)<br>
>><br>
>> 998 + return self._make_network_dict(network,<br>
>> process_extensions=False)<br>
>><br>
>> 999<br>
>><br>
>> 1000 def update_network(self, context, id, network):<br>
>><br>
>> 1001<br>
>><br>
>> n = network['network']<br>
>><br>
>><br>
>> -----------------------<br>
>><br>
>><br>
>> Regards,<br>
>> Nader.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Mar 7, 2014 at 6:26 AM, Robert Kukura <<a href="mailto:kukura@noironetworks.com">kukura@noironetworks.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On 3/7/14, 3:53 AM, Édouard Thuleau wrote:<br>
>>><br>
>>> Yes, that sounds good to be able to load extensions from a mechanism<br>
>>> driver.<br>
>>><br>
>>> But another problem I think we have with ML2 plugin is the list<br>
>>> extensions supported by default [1].<br>
>>> The extensions should only load by MD and the ML2 plugin should only<br>
>>> implement the Neutron core API.<br>
>>><br>
>>><br>
>>> Keep in mind that ML2 supports multiple MDs simultaneously, so no single<br>
>>> MD can really control what set of extensions are active. Drivers need to be<br>
>>> able to load private extensions that only pertain to that driver, but we<br>
>>> also need to be able to share common extensions across subsets of drivers.<br>
>>> Furthermore, the semantics of the extensions need to be correct in the face<br>
>>> of multiple co-existing drivers, some of which know about the extension, and<br>
>>> some of which don't. Getting this properly defined and implemented seems<br>
>>> like a good goal for juno.<br>
>>><br>
>>> -Bob<br>
>>><br>
>>><br>
>>><br>
>>> Any though ?<br>
>>> Édouard.<br>
>>><br>
>>> [1]<br>
>>> <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L87" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L87</a><br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Mar 7, 2014 at 8:32 AM, Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> I think it is better to continue the discussion here. It is a good log<br>
>>>> :-)<br>
>>>><br>
>>>> Eugine and I talked the related topic to allow drivers to load<br>
>>>> extensions) in Icehouse Summit<br>
>>>> but I could not have enough time to work on it during Icehouse.<br>
>>>> I am still interested in implementing it and will register a blueprint<br>
>>>> on it.<br>
>>>><br>
>>>> etherpad in icehouse summit has baseline thought on how to achieve it.<br>
>>>> <a href="https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension" target="_blank">https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension</a><br>
>>>> I hope it is a good start point of the discussion.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Akihiro<br>
>>>><br>
>>>> On Fri, Mar 7, 2014 at 4:07 PM, Nader Lahouti <<a href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
>>>> wrote:<br>
>>>> > Hi Kyle,<br>
>>>> ><br>
>>>> > Just wanted to clarify: Should I continue using this mailing list to<br>
>>>> > post my<br>
>>>> > question/concerns about ML2? Please advise.<br>
>>>> ><br>
>>>> > Thanks,<br>
>>>> > Nader.<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > On Thu, Mar 6, 2014 at 1:50 PM, Kyle Mestery<br>
>>>> > <<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> Thanks Edgar, I think this is the appropriate place to continue this<br>
>>>> >> discussion.<br>
>>>> >><br>
>>>> >><br>
>>>> >> On Thu, Mar 6, 2014 at 2:52 PM, Edgar Magana <<a href="mailto:emagana@plumgrid.com">emagana@plumgrid.com</a>><br>
>>>> >> wrote:<br>
>>>> >>><br>
>>>> >>> Nader,<br>
>>>> >>><br>
>>>> >>> I would encourage you to first discuss the possible extension with<br>
>>>> >>> the<br>
>>>> >>> ML2 team. Rober and Kyle are leading this effort and they have a IRC<br>
>>>> >>> meeting<br>
>>>> >>> every week:<br>
>>>> >>><br>
>>>> >>> <a href="https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting" target="_blank">https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting</a><br>
>>>> >>><br>
>>>> >>> Bring your concerns on this meeting and get the right feedback.<br>
>>>> >>><br>
>>>> >>> Thanks,<br>
>>>> >>><br>
>>>> >>> Edgar<br>
>>>> >>><br>
>>>> >>> From: Nader Lahouti <<a href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
>>>> >>> Reply-To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>>> >>> Date: Thursday, March 6, 2014 12:14 PM<br>
>>>> >>> To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>>> >>> Subject: Re: [openstack-dev] [Neutron][ML2]<br>
>>>> >>><br>
>>>> >>> Hi Aaron,<br>
>>>> >>><br>
>>>> >>> I appreciate your reply.<br>
>>>> >>><br>
>>>> >>> Here is some more details on what I'm trying to do:<br>
>>>> >>> I need to add new attribute to the network resource using extensions<br>
>>>> >>> (i.e. network config profile) and use it in the mechanism driver (in<br>
>>>> >>> the<br>
>>>> >>> create_network_precommit/postcommit).<br>
>>>> >>> If I use current implementation of Ml2Plugin, when a call is made to<br>
>>>> >>> mechanism driver's create_network_precommit/postcommit the new<br>
>>>> >>> attribute is<br>
>>>> >>> not included in the 'mech_context'<br>
>>>> >>> Here is code from Ml2Plugin:<br>
>>>> >>> class Ml2Plugin(...):<br>
>>>> >>> ...<br>
>>>> >>> def create_network(self, context, network):<br>
>>>> >>> net_data = network['network']<br>
>>>> >>> ...<br>
>>>> >>> with session.begin(subtransactions=True):<br>
>>>> >>> self._ensure_default_security_group(context, tenant_id)<br>
>>>> >>> result = super(Ml2Plugin, self).create_network(context,<br>
>>>> >>> network)<br>
>>>> >>> network_id = result['id']<br>
>>>> >>> ...<br>
>>>> >>> mech_context = driver_context.NetworkContext(self,<br>
>>>> >>> context,<br>
>>>> >>> result)<br>
>>>> >>><br>
>>>> >>> self.mechanism_manager.create_network_precommit(mech_context)<br>
>>>> >>><br>
>>>> >>> Also need to include new extension in the<br>
>>>> >>> _supported_extension_aliases.<br>
>>>> >>><br>
>>>> >>> So to avoid changes in the existing code, I was going to create my<br>
>>>> >>> own<br>
>>>> >>> plugin (which will be very similar to Ml2Plugin) and use it as<br>
>>>> >>> core_plugin.<br>
>>>> >>><br>
>>>> >>> Please advise the right solution implementing that.<br>
>>>> >>><br>
>>>> >>> Regards,<br>
>>>> >>> Nader.<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> On Wed, Mar 5, 2014 at 11:49 PM, Aaron Rosen <<a href="mailto:aaronorosen@gmail.com">aaronorosen@gmail.com</a>><br>
>>>> >>> wrote:<br>
>>>> >>>><br>
>>>> >>>> Hi Nader,<br>
>>>> >>>><br>
>>>> >>>> Devstack's default plugin is ML2. Usually you wouldn't 'inherit'<br>
>>>> >>>> one<br>
>>>> >>>> plugin in another. I'm guessing you probably wire a driver that<br>
>>>> >>>> ML2 can use<br>
>>>> >>>> though it's hard to tell from the information you've provided what<br>
>>>> >>>> you're<br>
>>>> >>>> trying to do.<br>
>>>> >>>><br>
>>>> >>>> Best,<br>
>>>> >>>><br>
>>>> >>>> Aaron<br>
>>>> >>>><br>
>>>> >>>><br>
>>>> >>>> On Wed, Mar 5, 2014 at 10:42 PM, Nader Lahouti<br>
>>>> >>>> <<a href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
>>>> >>>> wrote:<br>
>>>> >>>>><br>
>>>> >>>>> Hi All,<br>
>>>> >>>>><br>
>>>> >>>>> I have a question regarding ML2 plugin in neutron:<br>
>>>> >>>>> My understanding is that, 'Ml2Plugin' is the default core_plugin<br>
>>>> >>>>> for<br>
>>>> >>>>> neutron ML2. We can use either the default plugin or our own<br>
>>>> >>>>> plugin (i.e.<br>
>>>> >>>>> my_ml2_core_plugin that can be inherited from Ml2Plugin) and use<br>
>>>> >>>>> it as<br>
>>>> >>>>> core_plugin.<br>
>>>> >>>>><br>
>>>> >>>>> Is my understanding correct?<br>
>>>> >>>>><br>
>>>> >>>>><br>
>>>> >>>>> Regards,<br>
>>>> >>>>> Nader.<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>
>>>> >>> _______________________________________________ OpenStack-dev<br>
>>>> >>> mailing<br>
>>>> >>> list <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>
>>>> >>> 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>
>>>> 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>
>>> _______________________________________________<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>
><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>