Open Stack

Vinay,

It shows it is public and everyone can see the info.

Thanks,
Nader.


On Tue, Mar 18, 2014 at 8:39 AM, Vinay Bannai <vbannai at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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/20140318/29219bd6/attachment-0001.html>