Thanks Mathieu for your reply. 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.
For Bug 1201957 I sent email to Salvatore and waiting for his reply. Thanks, Nader. On Mon, Mar 17, 2014 at 3:05 AM, Mathieu Rohon <mathieu.ro...@gmail.com>wrote: > Hi > > On Fri, Mar 7, 2014 at 7:33 PM, 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? > > I don't think you should create your own Plugin, having a MD is > simpler to develop and to maintain, > you should just help us make ML2 evolve on the good path that feet > your needs. Moreover, > having MD to be able to load extensions is already identified, as Akihiro > said. > Developing this part would be more usefull for you and for the entire ML2 > users. > > > 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? > > As you underlined it, it shouldn't be disabled since MD might need to > have the entire network dict, > with extensions data. You might contact salvatore to talk about > another workaround for its bug. > > > ---------- > > 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 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
