<div dir="ltr">Thanks Mathieu for your reply.<div style>I implemented the code in the Ml2Plugin and based on the aliases defined in the mechanism driver, it update the support aliases in the plugin. So I can avoid having another ml2 plugin.</div>
<div style><br></div><div style>For <span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">Bug 1201957 </span>I sent email to S<span style="font-family:arial,sans-serif;font-size:13px">alvatore and waiting for his reply.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Nader.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"> </span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 3:05 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<br>
<div class=""><br>
On Fri, Mar 7, 2014 at 7:33 PM, Nader Lahouti <<a href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>> wrote:<br>
> 1) Does it mean an interim solution is to have our own plugin (and have all<br>
> the changes in it) and declare it as core_plugin instead of Ml2Plugin?<br>
<br>
</div>I don't think you should create your own Plugin, having a MD is<br>
simpler to develop and to maintain,<br>
you should just help us make ML2 evolve on the good path that feet<br>
your needs. Moreover,<br>
having MD to be able to load extensions is already identified, as Akihiro said.<br>
Developing this part would be more usefull for you and for the entire ML2 users.<br>
<div class=""><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 a<br>
> 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>
</div>As you underlined it, it shouldn't be disabled since MD might need to<br>
have the entire network dict,<br>
with extensions data. You might contact salvatore to talk about<br>
another workaround for its bug.<br>
<div class=""><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>> ...<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 extensions<br>
>> 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 on<br>
>>> 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>
>>> >>> <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' one<br>
>>> >>>> plugin in another. I'm guessing you probably wire a driver that ML2<br>
>>> >>>> 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 plugin<br>
>>> >>>>> (i.e.<br>
>>> >>>>> my_ml2_core_plugin that can be inherited from Ml2Plugin) and use it<br>
>>> >>>>> 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 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>
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>