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.laho...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, Andre Pech <ap...@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 <ap...@aristanetworks.com> wrote: On Fri, Mar 28, 2014 at 6:44 PM, Nader Lahouti <nader.laho...@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.ro...@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.laho...@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 < ap...@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.laho...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<inline: graycol.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev