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 <amot...@gmail.com
<mailto:amot...@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.laho...@gmail.com <mailto:nader.laho...@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
<mest...@noironetworks.com <mailto:mest...@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
<emag...@plumgrid.com <mailto:emag...@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.laho...@gmail.com
<mailto:nader.laho...@gmail.com>>
>>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
>>> Date: Thursday, March 6, 2014 12:14 PM
>>> To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@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
<aaronoro...@gmail.com <mailto:aaronoro...@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.laho...@gmail.com <mailto:nader.laho...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>>>>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> _______________________________________________ OpenStack-dev
mailing
>>> list OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
