-- 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.
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
