Open Stack

Akihiro,

I understand you want to distinguish "setting to null" from "reset to default".
I was simply looking at the first use case and not considering at all
the second.
If we want to go this route on the cli it's probably advisable to use
--param-clear and --param-reset options.
However on the API server this is problematic.

Currently UPDATE operations adopt PATCH semantics. So we can't use the
approach of interpreting a missing attribute as a 'reset to default'.
Moving away from these semantics would clear be an incompatible
change, and should probably be ruled out for Grizzly.
While we have a solution for 'clearing' an attribute, as well as one
for setting it to 'empty', the only approach I can think of for a
'reset to default' action is... an API action actually. Something
along the lines of:

PUT /v2.0/subnets/<subnet_id>/reset_attributes

{'attributes': ['gateway_ip', 'ip_version'}}

Still, I would like to understand what the rationale for this kind of
behaviour. I've never stumbled upon in the past over an API where
individual attributes could be restored to its 'default value'. In the
case of a subnet, would the default 'gateway_ip' be the one which was
set when the resource is created, or the one that quantum would have
created if it were not specified in the POST request (ie: the first IP
of the CIDR).

Regards,
Salvatore


On 9 February 2013 14:52, Akihiro MOTOKI <motoki at da.jp.nec.com> wrote:
> Hi,
>
> I sent the following mail when action=clear was discussed.
> My concern is that "clear" (reset to the default) and "no-<param_name>"
> have different meaning in some case. A good example is gateway_ip.
>
> I agree we should have better usability and maintainability.
>
> ------------------------------------------------------------
> During the review https://review.openstack.org/#/c/18018/,
> A question on the API layer has been raised: What is the meaning of 'None'?
>
> In the review a problem that a meaning of passing 'None' in Quantum API
> (action=clear) for an attribute is ambiguous has been raised.
> A word "clear" is used in two meanings: (a) to set an empty value,
> and (b) to reset to default.
>
> These are similar in many cases, but they have different meanings.
> For example, let's assume attribute X is a list and its default value is [1,2].
> "Setting an empty value" means that [] is set to X, and "reseting to default"
> means that [1,2] is set to X.
>
> I believe these two should be distinguished on the API layer.
> The API layer shoule provide:
> - a way to set an empty value (e.g., "", [], {}), and
> - a way to reset to its default value
>
> IMO, the former is innevitable since the API should not limit a value which
> is valid for a specific attribute, and the latter is very useful if supported.
> ------------------------------------------------------------
>
>>>>>> Date: Fri, 8 Feb 2013 18:55:14 +0000
>>>>>> From: Salvatore Orlando <sorlando at nicira.com>
>>>>>> Subject: Re: [openstack-dev] [quantum][CLI]Specifying None values toattributes.
>>
>> This is an important usability topic with have fallen a bit behind.
>> I recall Gary's proposal around an explicit 'clear' action, and I
>> remember Yong also has a patch for it.
>>
>> I don't remember whether there was consensus on it; my concern was
>> just that from an usability and maintainability perspective probably
>> we can do better (what would be the possible actions beyond clearing
>> and setting it, where setting is achieved with an '='?, also I
>> generally tend to refrain from using magic values, because they always
>> caused me more pain than gain in the past).
>>
>> Actually, we already do this through the CLI, although in a fairly
>> hardcoded way.
>> We can set a gateway_ip to null for a subnet with the --no-gateway option;
>> we can also remove the external gateway for a router with the
>> router-gateway-clear command.
>> I would cast my vote for allowing the CLI to add a --no-<param_name>
>> option for all the parameters that can be cleared.
>> Another options that can be considered stems from CLI tools like
>> ovs-vsctl or xe.
>>
>> with ovs-vsctl I can nullify a OVS DB entry with ovs-vsctl clear
>> <table> <record> <column>
>> with xe I can nullify a parameter with xe <resource>-param-clear <param_name>
>>
>> For instance we could do:
>> quantum subnet-update <subnet_id> --clear gateway_ip
>> or
>> quantum router-update <router_id> --clear external_network_info
>>
>> NOTE: I'm not advocating changes to CLI for existing commands; this is
>> just an example.
>>
>> Salvatore
>>
>>
>> On 8 February 2013 18:10, Dan Wendlandt <dan at nicira.com> wrote:
>> >
>> >
>> > On Fri, Feb 8, 2013 at 7:10 AM, Roman Prykhodchenko
>> > <rprikhodchenko at mirantis.com> wrote:
>> >>
>> >> I assume I should ping the community again about this issue. Does anyone
>> >> have any thought on this?
>> >
>> >
>> > Hi Roman,
>> >
>> > Sorry, I think people on the team a bit overwhelmed with reviews + the G-3
>> > deadline, and are probably behind on general list email.
>> >
>> > I agree that this is a general problem.  Yong, Mark, and Salvatore are
>> > probably the most relevant people to answer this question, as I'm not up to
>> > date on these client / API discussions.  I'll ping them and encourage them
>> > to comment on-list.
>> >
>> > Dan
>> >
>> >
>> >
>> >>
>> >>
>> >>
>> >> - Roman
>> >>
>> >>
>> >> On Tue, Feb 5, 2013 at 1:24 PM, Roman Prykhodchenko
>> >> <rprikhodchenko at mirantis.com> wrote:
>> >>>
>> >>> Hi folks!
>> >>>
>> >>> Recently I implemented a patch that allows resetting session persistence
>> >>> for a VIP: https://review.openstack.org/#/c/20725/.
>> >>> What I noticed is that it's not possible to use this feature from the
>> >>> command line. The problem seems to be quite general because there's no way
>> >>> of specifying None values for attributes.
>> >>>
>> >>> As some of you noticed in the review Yong (gongysh) has made some changes
>> >>> that allow to specify action=clear in the quantum-client's shell and that
>> >>> will send a None value: https://review.openstack.org/#/c/17436/.
>> >>> Unfortunately that change is abandoned right now because we didn't came up
>> >>> with a consensus about dealing with None values in command line environment.
>> >>>
>> >>> I think it's reasonable to re-initiate this discussion because specifying
>> >>> None values from the command line is quite a necessary thing now and it
>> >>> needs a generic solution.
>> >>>
>> >>>
>> >>> - Roman
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > --
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > Dan Wendlandt
>> > Nicira, Inc: www.nicira.com
>> > twitter: danwendlandt
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >
>> > _______________________________________________
>> > 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