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