1) Does it mean an interim solution is to have our own plugin (and have all
the changes in it) and declare it as core_plugin instead of Ml2Plugin?
2) The other issue as I mentioned before, is that the extension(s) is not
showing up in the result, for instance when create_network is called
[*result = super(Ml2Plugin, self).create_network(context, network)]*, and
as a result they cannot be used in the mechanism drivers when needed.
Looks like the process_extensions is disabled when fix for Bug 1201957
committed and here is the change:
Any idea why it is disabled?
----------
Avoid performing extra query for fetching port security binding
Bug 1201957
Add a relationship performing eager load in Port and Network
models, thus preventing the 'extend' function from performing
an extra database query.
Also fixes a comment in securitygroups_db.py
Change-Id: If0f0277191884aab4dcb1ee36826df7f7d66a8fa
master h.1
...
2013.2
commit f581b2faf11b49852b0e1d6f2ddd8d19b8b69cdf 1 parent ca421e7
Salvatore Orlando salv-orlando authored 8 months ago
2 neutron/db/db_base_plugin_v2.py View
@@ -995,7 +995,7 @@ def create_network(self, context, network):
995 'status': constants.NET_STATUS_ACTIVE}
996 network = models_v2.Network(**args)
997 context.session.add(network)
*998 - return self._make_network_dict(network)*
*998 + return self._make_network_dict(network,
process_extensions=False)*
999
1000 def update_network(self, context, id, network):
1001
n = network['network']
-----------------------
Regards,
Nader.
On Fri, Mar 7, 2014 at 6:26 AM, Robert Kukura <kuk...@noironetworks.com>wrote:
>
> On 3/7/14, 3:53 AM, Édouard Thuleau wrote:
>
> Yes, that sounds good to be able to load extensions from a mechanism
> driver.
>
> But another problem I think we have with ML2 plugin is the list extensions
> supported by default [1].
> The extensions should only load by MD and the ML2 plugin should only
> implement the Neutron core API.
>
>
> Keep in mind that ML2 supports multiple MDs simultaneously, so no single
> MD can really control what set of extensions are active. Drivers need to be
> able to load private extensions that only pertain to that driver, but we
> also need to be able to share common extensions across subsets of drivers.
> Furthermore, the semantics of the extensions need to be correct in the face
> of multiple co-existing drivers, some of which know about the extension,
> and some of which don't. Getting this properly defined and implemented
> seems like a good goal for juno.
>
> -Bob
>
>
>
> Any though ?
> Édouard.
>
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L87
>
>
>
> On Fri, Mar 7, 2014 at 8:32 AM, Akihiro Motoki <amot...@gmail.com> wrote:
>
>> Hi,
>>
>> I think it is better to continue the discussion here. It is a good log :-)
>>
>> Eugine and I talked the related topic to allow drivers to load
>> extensions) in Icehouse Summit
>> but I could not have enough time to work on it during Icehouse.
>> I am still interested in implementing it and will register a blueprint on
>> it.
>>
>> etherpad in icehouse summit has baseline thought on how to achieve it.
>> https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension
>> I hope it is a good start point of the discussion.
>>
>> Thanks,
>> Akihiro
>>
>> On Fri, Mar 7, 2014 at 4:07 PM, Nader Lahouti <nader.laho...@gmail.com>
>> wrote:
>> > Hi Kyle,
>> >
>> > Just wanted to clarify: Should I continue using this mailing list to
>> post my
>> > question/concerns about ML2? Please advise.
>> >
>> > Thanks,
>> > Nader.
>> >
>> >
>> >
>> > On Thu, Mar 6, 2014 at 1:50 PM, Kyle Mestery <mest...@noironetworks.com
>> >
>> > wrote:
>> >>
>> >> Thanks Edgar, I think this is the appropriate place to continue this
>> >> discussion.
>> >>
>> >>
>> >> On Thu, Mar 6, 2014 at 2:52 PM, Edgar Magana <emag...@plumgrid.com>
>> wrote:
>> >>>
>> >>> Nader,
>> >>>
>> >>> I would encourage you to first discuss the possible extension with the
>> >>> ML2 team. Rober and Kyle are leading this effort and they have a IRC
>> meeting
>> >>> every week:
>> >>> https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting
>> >>>
>> >>> Bring your concerns on this meeting and get the right feedback.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Edgar
>> >>>
>> >>> From: Nader Lahouti <nader.laho...@gmail.com>
>> >>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
>> >>> Date: Thursday, March 6, 2014 12:14 PM
>> >>> To: OpenStack List <openstack-dev@lists.openstack.org>
>> >>> Subject: Re: [openstack-dev] [Neutron][ML2]
>> >>>
>> >>> Hi Aaron,
>> >>>
>> >>> I appreciate your reply.
>> >>>
>> >>> Here is some more details on what I'm trying to do:
>> >>> I need to add new attribute to the network resource using extensions
>> >>> (i.e. network config profile) and use it in the mechanism driver (in
>> the
>> >>> create_network_precommit/postcommit).
>> >>> If I use current implementation of Ml2Plugin, when a call is made to
>> >>> mechanism driver's create_network_precommit/postcommit the new
>> attribute is
>> >>> not included in the 'mech_context'
>> >>> Here is code from Ml2Plugin:
>> >>> class Ml2Plugin(...):
>> >>> ...
>> >>> def create_network(self, context, network):
>> >>> net_data = network['network']
>> >>> ...
>> >>> with session.begin(subtransactions=True):
>> >>> self._ensure_default_security_group(context, tenant_id)
>> >>> result = super(Ml2Plugin, self).create_network(context,
>> >>> network)
>> >>> network_id = result['id']
>> >>> ...
>> >>> mech_context = driver_context.NetworkContext(self,
>> context,
>> >>> result)
>> >>>
>> self.mechanism_manager.create_network_precommit(mech_context)
>> >>>
>> >>> Also need to include new extension in the
>> _supported_extension_aliases.
>> >>>
>> >>> So to avoid changes in the existing code, I was going to create my own
>> >>> plugin (which will be very similar to Ml2Plugin) and use it as
>> core_plugin.
>> >>>
>> >>> Please advise the right solution implementing that.
>> >>>
>> >>> Regards,
>> >>> Nader.
>> >>>
>> >>>
>> >>> On Wed, Mar 5, 2014 at 11:49 PM, Aaron Rosen <aaronoro...@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Hi Nader,
>> >>>>
>> >>>> Devstack's default plugin is ML2. Usually you wouldn't 'inherit' one
>> >>>> plugin in another. I'm guessing you probably wire a driver that ML2
>> can use
>> >>>> though it's hard to tell from the information you've provided what
>> you're
>> >>>> trying to do.
>> >>>>
>> >>>> Best,
>> >>>>
>> >>>> Aaron
>> >>>>
>> >>>>
>> >>>> On Wed, Mar 5, 2014 at 10:42 PM, Nader Lahouti <
>> nader.laho...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi All,
>> >>>>>
>> >>>>> I have a question regarding ML2 plugin in neutron:
>> >>>>> My understanding is that, 'Ml2Plugin' is the default core_plugin for
>> >>>>> neutron ML2. We can use either the default plugin or our own plugin
>> (i.e.
>> >>>>> my_ml2_core_plugin that can be inherited from Ml2Plugin) and use it
>> as
>> >>>>> core_plugin.
>> >>>>>
>> >>>>> Is my understanding correct?
>> >>>>>
>> >>>>>
>> >>>>> Regards,
>> >>>>> Nader.
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OpenStack-dev mailing list
>> >>>>> OpenStack-dev@lists.openstack.org
>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> OpenStack-dev mailing list
>> >>>> OpenStack-dev@lists.openstack.org
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>
>> >>> _______________________________________________ OpenStack-dev mailing
>> >>> list OpenStack-dev@lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>> _______________________________________________
>> >>> OpenStack-dev mailing list
>> >>> OpenStack-dev@lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
