[openstack-dev] [Neutron][ML2] Can I use a new plugin based on Ml2Plugin instead of Ml2Plugin as core_plugin

Nader Lahouti nader.lahouti at gmail.com
Thu Mar 13 17:07:48 UTC 2014


-- 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.


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/2eda84b2/attachment.html>


More information about the OpenStack-dev mailing list