Can't access the BP. Says it is private.
On Mon, Mar 17, 2014 at 7:03 PM, Nader Lahouti <nader.laho...@gmail.com>wrote: > Sure. I filed new BP that address this issue: > > https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions > > Thanks, > Nader. > > > > On Mon, Mar 17, 2014 at 3:26 PM, Kyle Mestery > <mest...@noironetworks.com>wrote: > >> On Mon, Mar 17, 2014 at 4:53 PM, Nader Lahouti >> <nader.laho...@gmail.com>wrote: >> >>> Thanks Kyle for the reply. >>> I added the code in the Ml2Plugin to include extensions in mechanism >>> driver, if they exist. >>> Hopefully I can commit it as part of this BP: >>> >>> https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support >>> >>> Great Nader! I think it makes more sense to have a new BP for this work, >> as it's not tied >> directly to the DFA work. Can you file one? Also, this will not land >> until Juno as we're in >> the RC for Icehouse now. >> >> Thanks, >> Kyle >> >> Thanks, >>> Nader. >>> >>> >>> >>> On Mon, Mar 17, 2014 at 6:31 AM, Kyle Mestery <mest...@noironetworks.com >>> > wrote: >>> >>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev