[openstack-dev] [Neutron][ML2]
Nader Lahouti
nader.lahouti at gmail.com
Tue Mar 18 00:08:36 UTC 2014
Thanks Mathieu for your reply.
I implemented the code in the Ml2Plugin and based on the aliases defined in
the mechanism driver, it update the support aliases in the plugin. So I can
avoid having another ml2 plugin.
For Bug 1201957 I sent email to Salvatore and waiting for his reply.
Thanks,
Nader.
On Mon, Mar 17, 2014 at 3:05 AM, Mathieu Rohon <mathieu.rohon at gmail.com>wrote:
> Hi
>
> On Fri, Mar 7, 2014 at 7:33 PM, 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?
>
> I don't think you should create your own Plugin, having a MD is
> simpler to develop and to maintain,
> you should just help us make ML2 evolve on the good path that feet
> your needs. Moreover,
> having MD to be able to load extensions is already identified, as Akihiro
> said.
> Developing this part would be more usefull for you and for the entire ML2
> users.
>
> > 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?
>
> As you underlined it, it shouldn't be disabled since MD might need to
> have the entire network dict,
> with extensions data. You might contact salvatore to talk about
> another workaround for its bug.
>
> > ----------
> > 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/ffa81128/attachment.html>
More information about the OpenStack-dev
mailing list