Open Stack

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
>