[openstack-dev] [Neutron][ML2]
Robert Kukura
kukura at noironetworks.com
Fri Mar 7 14:26:27 UTC 2014
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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
> <mailto:nader.lahouti at gmail.com>>
> >>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> >>> Date: Thursday, March 6, 2014 12:14 PM
> >>> To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto: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 <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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/20140307/c4e7911a/attachment.html>
More information about the OpenStack-dev
mailing list