[openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:
Nader Lahouti
nader.lahouti at gmail.com
Sat Mar 29 01:44:44 UTC 2014
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.
* 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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140328/74fd0517/attachment.html>
More information about the OpenStack-dev
mailing list