Open Stack

Can't access the BP. Says it is private.


On Mon, Mar 17, 2014 at 7:03 PM, Nader Lahouti <nader.lahouti at gmail.com>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 <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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vinay Bannai
Email: vbannai at gmail.com
Google Voice: 415 938 7576
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140318/7349317e/attachment.html>