<br><br><div class="gmail_quote">On Thu, Aug 9, 2012 at 11:04 AM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Folks, Yong<br>
<br>
In previous netstack IRC meeting, we agreed to use null to specify None.<br>
However you have a new idea for that spec.<br>
<br>
======<br>
My opinion is: On the server side, we treat empty string and None<br>
itself as None. So that We don't need to modify our cli command since<br>
we can use --gateway_ip= to pass in empty string to server. and Other<br>
application can pass in None itself in Json too.<br>
======<br>
<a href="https://review.openstack.org/#/c/10749/" target="_blank">https://review.openstack.org/#/c/10749/</a><br>
<br>
So now there are two spec alternatives.<br>
(Spec1) null<br>
(Spec2) null or ""<br>
<br>
Honestly, I don't case ether of that if all API will follow one spec<br>
consistently.<br>
So let's decide the spec in this thread.<br></blockquote><div><br></div><div>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.  Otherwise, "" means different things depending on the parameter (since its value to send in "" to mean the empty string for fields like name).  </div>

<div><br></div><div>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?</div><div><br></div><div>Dan</div><div>

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>