On Thu, Mar 13, 2014 at 12:07 PM, Nader Lahouti <nader.laho...@gmail.com>wrote:
> -- edited the subject > > I'm resending this question. > The issue is described in email thread and. In brief, I need to add load > new extensions and it seems the mechanism driver does not support that. In > order to do that I was thinking to have a new ml2 plugin base on existing > Ml2Plugin and add my changes there and have it as core_plugin. > Please read the email thread and glad to have your suggestion. > > Nader, as has been pointed out in the prior thread, it would be best to not write a new core plugin copied from ML2. A much better approach would be to work to make the extension loading function in the existing ML2 plugin, as this will benefit all users of ML2. Thanks, Kyle > > On Fri, Mar 7, 2014 at 10:33 AM, Nader Lahouti <nader.laho...@gmail.com>wrote: > >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev