Vinay, It shows it is public and everyone can see the info.
Thanks, Nader. On Tue, Mar 18, 2014 at 8:39 AM, Vinay Bannai <[email protected]> wrote: > Can't access the BP. Says it is private. > > > On Mon, Mar 17, 2014 at 7:03 PM, Nader Lahouti <[email protected]>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 >> <[email protected]>wrote: >> >>> On Mon, Mar 17, 2014 at 4:53 PM, Nader Lahouti >>> <[email protected]>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 < >>>> [email protected]> wrote: >>>> >>>>> On Thu, Mar 13, 2014 at 12:07 PM, Nader Lahouti < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 >>>>>>>> <[email protected]>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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> >>>>>>>>> > 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 < >>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>> >>> Reply-To: OpenStack List <[email protected]> >>>>>>>>> >>> Date: Thursday, March 6, 2014 12:14 PM >>>>>>>>> >>> To: OpenStack List <[email protected]> >>>>>>>>> >>> 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 < >>>>>>>>> [email protected]> >>>>>>>>> >>> 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 < >>>>>>>>> [email protected]> >>>>>>>>> >>>> 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 >>>>>>>>> >>>>> [email protected] >>>>>>>>> >>>>> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> _______________________________________________ >>>>>>>>> >>>> OpenStack-dev mailing list >>>>>>>>> >>>> [email protected] >>>>>>>>> >>>> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>> >>>>>>>>> >>> >>>>>>>>> >>> _______________________________________________ OpenStack-dev >>>>>>>>> mailing >>>>>>>>> >>> list [email protected] >>>>>>>>> >>> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>> >>>>>>>>> >>> _______________________________________________ >>>>>>>>> >>> OpenStack-dev mailing list >>>>>>>>> >>> [email protected] >>>>>>>>> >>> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> OpenStack-dev mailing list >>>>>>>>> >> [email protected] >>>>>>>>> >> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > OpenStack-dev mailing list >>>>>>>>> > [email protected] >>>>>>>>> > >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> > >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenStack-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenStack-dev mailing >>>>>>>> [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenStack-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> [email protected] >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Vinay Bannai > Email: [email protected] > Google Voice: 415 938 7576 > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
