Open Stack

On Thu, Mar 13, 2014 at 12:07 PM, Nader Lahouti <nader.lahouti at gmail.com>wrote:

> -- 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.
>
> Nader, as has been pointed out in the prior thread, it would be best to
not write a
new core plugin copied from ML2. A much better approach would be to work to
make the extension loading function in the existing ML2 plugin, as this will
benefit all users of ML2.

Thanks,
Kyle


>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/cff540e3/attachment.html>