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 >> <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.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
