[openstack-dev] [Neutron][ML2]

Akihiro Motoki amotoki at gmail.com
Fri Mar 7 07:32:40 UTC 2014


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
>



More information about the OpenStack-dev mailing list