[openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:
Mohammad Banikazemi
mb at us.ibm.com
Fri Apr 4 02:49:36 UTC 2014
Nader,
During the last ML2 IRC weekly meeting [1] having per-MD extensions was
mentioned. This is an important topic in my opinion. You may want to add a
proposal for a design session on this topic at [2] and/or add this topic to
the agenda for the next ML2 weekly meeting [3] for further discussion.
Mohammad
[1]
http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-04-02-16.00.log.html
[2] http://summit.openstack.org
[3] https://wiki.openstack.org/wiki/Meetings/ML2
From: Nader Lahouti <nader.lahouti at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>, Andre Pech
<apech at aristanetworks.com>,
Date: 04/03/2014 01:16 PM
Subject: Re: [openstack-dev] [Neutron][ML2][Ml2Plugin] Setting
_original_network in NetworkContext:
Thanks a lot Andre for the reply.
My comments inline:
On Wed, Apr 2, 2014 at 12:37 PM, Andre Pech <apech at aristanetworks.com>
wrote:
On Fri, Mar 28, 2014 at 6:44 PM, Nader Lahouti <nader.lahouti at gmail.com>
wrote:
Hi Mathieu,
Thanks a lot for your reply.
Even in the neutron/neutron/db/db_base_plugin_v2.py: create_network()
passes network object:
911 def create_network(self, context, network):
912 """Handle creation of a single network."""
913 # single request processing
914 n = network['network'] <<<<<<<<==== 'n' has all the
network info (including extensions)
915 # NOTE(jkoelker) Get the tenant_id outside of the session to
avoid
916 # unneeded db action if the operation raises
917 tenant_id = self._get_tenant_id_for_create(context, n)
918 with context.session.begin(subtransactions=True):
919 args = {'tenant_id': tenant_id,
920 'id': n.get('id') or uuidutils.generate_uuid(),
921 'name': n['name'],
922 'admin_state_up': n['admin_state_up'],
923 'shared': n['shared'],
924 'status': n.get('status', constants.
NET_STATUS_ACTIVE)}
925 network = models_v2.Network(**args) <<= 'network' does
not include extensions.
926 context.session.add(network)
927 return self._make_network_dict(network, process_extensions=
False)
even if process_extensions set to True, we still have issue.
If using original_network, causes confusion can we add a new parameter
and use it in mechanism driver?
Also haven't received any reply from salvotore.
Yes, not re-using original_network would be my preference.
Will add new parameter to avoid re-using original_network.
* Another issue with the Ml2Plugin regarding the extensions is that
neutron api can fail as it cannot find any handler in the plugin for
request such as get/update/create/delete.
For instance I added 'config_profile' as an extensions to network
resource and get this error.
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
File
"/opt/stack/neutron/neutron/api/v2/base.py", line 273, in index
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
ret
urn self._items(request, True, parent_id)
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
File
"/opt/stack/neutron/neutron/api/v2/base.py", line 226, in _items
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
obj_getter = getattr(self._plugin, self._plugin_handlers[self.LIST])
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
AttributeError: 'Ml2Plugin' object has no attribute
'get_config_profiles'
2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
We need to add either (1) Make Ml2Plugin code aware of such an attribute
(e.g. adding another base class, which may not be a good solution) or
(2) make the changes in neutron/neutron/api/v2/base.py to understand if
Ml2Plugin is supported then get the attributes from mechanism driver.
(3) any other idea?
I already implemented (2) in my private repo, to fix this error.
Also, I have already opened a BP to for supporting extensions in MD, and
if it is okay I can include the fix as part of that BP.
Yes, we don't really have great support for extensions today, so fixing
this in the context of making extensions work in general with ML2 and
MechanismDrivers, this sounds great.
Thanks for taking this on,
Sure. Will add it as part of
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
Thanks,
Nader.
Andre
Thanks,
Nader.
On Fri, Mar 28, 2014 at 8:22 AM, Mathieu Rohon <mathieu.rohon at gmail.com>
wrote:
hi nader,
I don't think this parameter could be used in this case. As andre said
, tha original-network is usefull for update and delete commands. It
would led to misunderstandings if we use this param in other cases,
and particulary in create commands.
I'm still thinking that the result of super(Ml2Plugin,
self).create_network(context, network), should have network extension
informations[1]. did you talk with salvotore about reverting his
change and using another workaround?
[1]https://answers.launchpad.net/neutron/+question/245773
Mathieu
On Thu, Mar 27, 2014 at 5:24 PM, Nader Lahouti <
nader.lahouti at gmail.com> wrote:
> Hi Andre,
>
> Thans for your reply.
>
> There is no existing network. The scenario is for the first time
that we
> create a network with an extension. Consider, a mechanism driver
adds an
> attribute (through extensions) to the network resource. When user
creates a
> network, the attribute is set and it is present in the 'network'
parameter,
> when calling create_network() in Ml2Plugin.
> But when create_network_pre/post_commit is called, the attribute
won't be
> available to the mechanism driver. Because the attribute is not
included in
> network object passed to MD - as I mentioned in previous email, the
'result'
> does not have the new attribute.
>
>
> Thanks,
> Nader.
>
>
>
>
>
>
>
>
> On Wed, Mar 26, 2014 at 3:52 PM, Andre Pech <
apech at aristanetworks.com>
> wrote:
>>
>> Hi Nader,
>>
>> When I wrote this, the intention was that original_network only
really
>> makes sense during an update_network call (ie when there's an
existing
>> network that you are modifying). In a create_network call, the
assumption is
>> that no network exists yet, so there is no "original network" to
set.
>>
>> Can you provide a bit more detail on the case where there's an
existing
>> network when create_network is called? Sorry, I didn't totally
follow when
>> this would happen.
>>
>> Thanks
>> Andre
>>
>>
>> On Tue, Mar 25, 2014 at 8:45 AM, Nader Lahouti <
nader.lahouti at gmail.com>
>> wrote:
>>>
>>> Hi All,
>>>
>>> In the current Ml2Plugin code when 'create_network' is called, as
shown
>>> below:
>>>
>>>
>>>
>>> def create_network(self, context, network)
>>>
>>> net_data = network['network']
>>>
>>> ...
>>>
>>> session = context.session
>>>
>>> with session.begin(subtransactions=True):
>>>
>>> self._ensure_default_security_group(context,
tenant_id)
>>>
>>> result = super(Ml2Plugin, self).create_network
(context,
>>> network)
>>>
>>> ...
>>>
>>> mech_context = driver_context.NetworkContext(self,
context,
>>> result)
>>>
>>> self.mechanism_manager.create_network_precommit
(mech_context)
>>>
>>> ...
>>>
>>>
>>>
>>> the original_network parameter is not set (the default is None)
when
>>> instantiating NetworkContext, and as a result the mech_context has
only the
>>> value of network object returned from super(Ml2Plugin,
>>> self).create_network().
>>>
>>> This causes issue when a mechanism driver needs to use the
original
>>> network parameters (given to the create_network), specially when
extension
>>> is used for the network resources.
>>>
>>> (The 'result' only has the network attributes without extension
which is
>>> used to set the '_network' in the NetwrokContext object).
>>>
>>> Even using extension function registration using
>>>
>>> db_base_plugin_v2.NeutronDbPluginV2.register_dict_extend_funcs
(...) won't
>>> help as the network object that is passed to the registered
function does
>>> not include the extension parameters.
>>>
>>>
>>> Is there any reason that the original_network is not set when
>>> initializing the NetworkContext? Would that cause any issue to set
it to
>>> 'net_data' so that any mechanism driver can use original network
parameters
>>> as they are available when create_network is called?
>>>
>>>
>>> Appreciate your comments.
>>>
>>>
>>> Thanks,
>>>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/34fca145/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/34fca145/attachment.gif>
More information about the OpenStack-dev
mailing list
