Open Stack

On 9 August 2012 20:16, Dan Wendlandt <dan at nicira.com> wrote:

>
>
> On Thu, Aug 9, 2012 at 11:04 AM, Nachi Ueno <nachi at nttmcl.com> wrote:
>
>> 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.
>>
>
> I'd rather be explicit and have the API use only JSON null, rather than
> modify our API design to make writing the CLI easier.
>

Agree


>  Otherwise, "" means different things depending on the parameter (since
> its value to send in "" to mean the empty string for fields like name).
>

I'd say that the empty string is the most dangerous of the magic strings,
so I would prefer to avoid it, if possible.


>
> What about having a CLI flag convention for passing in a None value where
> it is allowed?  Like --no_gateway_ip , which would result in gateway_ip
> being set to null?
>

Totally agree. In general, for each nullable attribute in the API we could
have a keyword CLI parameter named --no_<attribute_name>


>
> Dan
>
>
>
>>
>> 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
>> >
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120810/2af7444f/attachment-0001.html>