Open Stack

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 <mestery at noironetworks.com>wrote:

> On Mon, Mar 17, 2014 at 4:53 PM, Nader Lahouti <nader.lahouti at 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 <mestery at noironetworks.com>wrote:
>>
>>> On Thu, Mar 13, 2014 at 12:07 PM, Nader Lahouti <nader.lahouti at 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.lahouti at 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 <
>>>>> kukura at 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 <amotoki at 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.lahouti at 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 <
>>>>>>> mestery at 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 <
>>>>>>> emagana at 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.lahouti at gmail.com>
>>>>>>> >>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>>>>>> >>> Date: Thursday, March 6, 2014 12:14 PM
>>>>>>> >>> To: OpenStack List <openstack-dev at 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 <
>>>>>>> aaronorosen at 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.lahouti at 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 at lists.openstack.org
>>>>>>> >>>>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> _______________________________________________
>>>>>>> >>>> OpenStack-dev mailing list
>>>>>>> >>>> OpenStack-dev at lists.openstack.org
>>>>>>> >>>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>> _______________________________________________ OpenStack-dev
>>>>>>> mailing
>>>>>>> >>> list OpenStack-dev at lists.openstack.org
>>>>>>> >>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >>>
>>>>>>> >>> _______________________________________________
>>>>>>> >>> OpenStack-dev mailing list
>>>>>>> >>> OpenStack-dev at lists.openstack.org
>>>>>>> >>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> OpenStack-dev mailing list
>>>>>>> >> OpenStack-dev at lists.openstack.org
>>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > OpenStack-dev mailing list
>>>>>>> > OpenStack-dev at lists.openstack.org
>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> >
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/1faa3cd9/attachment.html>