Open Stack

Some more thoughts inline.

Salvatore

On 10 February 2013 17:03, Akihiro MOTOKI <motoki at da.jp.nec.com> wrote:
> Hi Salvatore, Roman and folks,
>
> I relooked the past discussion in the abondaned review [1].
> I originally just want to set any value including "null"
> and do not necessarily want to "reset to default".
> During the review, "resetting the attr to initial default value" comes in
> and the meaning of "clear" looks unclear to me.
> We need to have a consensus what None means and
> it is the reason I raised this topic.

In my opinion 'resetting to initial default value' is somehow
ambiguous, and any API action which would try to do something like
that would be as well at least confusing to users.

>
> IMO it is important to provide a way to "setting to null"
> and "None" is an appropriate value for this.
> "reset to default" is not necessarily required.

100% Agree.

>
> Now we seem to have a rough consensus to use "None" to setting a
> corressponding attribute to null. Is it right?

Technically, we use 'null' (JSON null) in the API request, so that
this is then interpreted as None in Python code, and then written as
'NULL' in the database.
I think we all agree on the behaviour on the server side. We are still
looking for consensus about how to expose this on the CLI.

>
>
> In addition, thanks for the detail investigation on the API.
> I have not fully studied about the API...
>
> [1] https://review.openstack.org/#/c/18018/
>
> Thanks,
> Akihiro
>
>>>>>> Date: Sat, 9 Feb 2013 16:33:38 +0000
>>>>>> From: Salvatore Orlando <sorlando at nicira.com>
>>>>>> Subject: Re: [openstack-dev] [quantum][CLI] Specifying None values to attributes.
>>
>> 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