Open Stack

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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/ca8ec8a6/attachment.html>