[openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:
Nader Lahouti
nader.lahouti at gmail.com
Thu Apr 3 17:11:24 UTC 2014
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 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#911> *def* create_network <http://www.xrefs.info/neutron-icehouse-3/s?refs=create_network>(self <http://www.xrefs.info/neutron-icehouse-3/s?defs=self>, context <http://www.xrefs.info/neutron-icehouse-3/s?defs=context>, network <http://www.xrefs.info/neutron-icehouse-3/s?defs=network>):912 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#912> """Handle creation of a single network."""913 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#913> # single request processing914 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#914> n = network <http://www.xrefs.info/neutron-icehouse-3/s?defs=network>['network'] *<<<<<<<<==== 'n' has all the network info (including extensions)*915 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#915> # NOTE(jkoelker) Get the tenant_id outside of the session to avoid916 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#916> # unneeded db action if the operation raises917 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#917> tenant_id <http://www.xrefs.info/neutron-icehouse-3/s?defs=tenant_id> = self <http://www.xrefs.info/neutron-icehouse-3/s?defs=self>._get_tenant_id_for_create <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#_get_tenant_id_for_create>(context <http://www.xrefs.info/neutron-icehouse-3/s?defs=context>, n)918 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#918> *with* context <http://www.xrefs.info/neutron-icehouse-3/s?defs=context>.session <http://www.xrefs.info/neutron-icehouse-3/s?defs=session>.begin <http://www.xrefs.info/neutron-icehouse-3/s?defs=begin>(subtransactions <http://www.xrefs.info/neutron-icehouse-3/s?defs=subtransactions>=True <http://www.xrefs.info/neutron-icehouse-3/s?defs=True>):919 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#919> args <http://www.xrefs.info/neutron-icehouse-3/s?defs=args> = {'tenant_id': tenant_id <http://www.xrefs.info/neutron-icehouse-3/s?defs=tenant_id>,920 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#920> 'id': n.get <http://www.xrefs.info/neutron-icehouse-3/s?defs=get>('id') *or* uuidutils <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#uuidutils>.generate_uuid <http://www.xrefs.info/neutron-icehouse-3/s?defs=generate_uuid>(),921 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#921> 'name': n['name'],922 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#922> 'admin_state_up': n['admin_state_up'],923 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#923> 'shared': n['shared'],924 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#924> 'status': n.get <http://www.xrefs.info/neutron-icehouse-3/s?defs=get>('status', constants <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#constants>.NET_STATUS_ACTIVE <http://www.xrefs.info/neutron-icehouse-3/s?defs=NET_STATUS_ACTIVE>)}925 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#925> network <http://www.xrefs.info/neutron-icehouse-3/s?defs=network> = models_v2 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#models_v2>.Network <http://www.xrefs.info/neutron-icehouse-3/s?defs=Network>(**args <http://www.xrefs.info/neutron-icehouse-3/s?defs=args>) <<*= 'network' does not include extensions.*926 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#926> context <http://www.xrefs.info/neutron-icehouse-3/s?defs=context>.session <http://www.xrefs.info/neutron-icehouse-3/s?defs=session>.add <http://www.xrefs.info/neutron-icehouse-3/s?defs=add>(network <http://www.xrefs.info/neutron-icehouse-3/s?defs=network>)927 <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#927> *return* self <http://www.xrefs.info/neutron-icehouse-3/s?defs=self>._make_network_dict <http://www.xrefs.info/neutron-icehouse-3/xref/neutron/db/db_base_plugin_v2.py#_make_network_dict>(network <http://www.xrefs.info/neutron-icehouse-3/s?defs=network>, process_extensions <http://www.xrefs.info/neutron-icehouse-3/s?defs=process_extensions>=False <http://www.xrefs.info/neutron-icehouse-3/s?defs=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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/8c44d9aa/attachment-0001.html>
More information about the OpenStack-dev
mailing list