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
