Open Stack

Hi Folks, Yong

In previous netstack IRC meeting, we agreed to use null to specify None.
However you have a new idea for that spec.

======
My opinion is: On the server side, we treat empty string and None
itself as None. So that We don't need to modify our cli command since
we can use --gateway_ip= to pass in empty string to server. and Other
application can pass in None itself in Json too.
======
https://review.openstack.org/#/c/10749/

So now there are two spec alternatives.
(Spec1) null
(Spec2) null or ""

Honestly, I don't case ether of that if all API will follow one spec
consistently.
So let's decide the spec in this thread.

2012/8/6 Salvatore Orlando <sorlando at nicira.com>:
> Hi,
>
> To add some more context, we actually have a situation in which by default
> the attribute Nachi is referring to (gateway_ip) is auto-generated, and we
> are looking for a solution to tell the API that the gateway IP should not be
> generated at all.
> It could be argued that the right solution would probably be looking at the
> problem in a different way (e.g.: have "no gateway" as default behaviour)
>
> However, for the specific issues Nachi raised, I have been unable to find so
> far similar cases in other Openstack projects. If this is confirmed,
> whatever is decided here might set a precedent, so it is worth dealing with
> this problem in an appropriate way. This might also be important for
> "update" scenarios in which we want to delete (or nullify) the value for a
> specific attribute, as most OS APIs use patch semantics for PUT operations.
>
> My personal opinion is that I would avoid using values which are tantamount
> to 'magic values', such as the empty string. the string 'none', also is a
> magic value, although I have to admit it might be acceptable. My preferred
> choice at the moment is having:
>
> "resource" : {
> "nullable-attribute" : null
> }
>
> for JSON, and something like the following:
>
> <resource>
>   <nullable-attribute/>
> </resource>
>
> for XML. I am not sure however whether this will work well with the current
> deserializers we have.
>
> Assuming we will deal properly with patch semantics and nullable attributes
> in Grizzly, it also important IMHO that whatever choice we make here must
> not cause a backward incompatible API change in Grizzly.
>
> Thanks,
> Salvatore
>
>
> On 6 August 2012 20:14, Nachi Ueno <nachi at nttmcl.com> wrote:
>>
>> Hi folks
>>
>> In quantum, we can specify None as a parameter value  ( In this case
>> None is not default value ).
>> How we design this spec?
>>
>> Design1:  "None" ( String) is only allowed with case sensitive.
>> Design2:  null ( Json type ) ( This can't support XML )
>> Design3:  Allow multiple way. ( None none null "" (empty string) )
>>
>> I wanna choose consistent way in OpenStack projects.
>>
>> # I think a PTL for API spec is do needed to maintain consistency
>> between project...
>>
>> Nachi : NTT MCL
>>
>> _______________________________________________
>> 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
>