[openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:
Andre Pech
apech at aristanetworks.com
Wed Apr 2 19:37:22 UTC 2014
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.
>
> * 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,
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/9675cce2/attachment.html>
More information about the OpenStack-dev
mailing list