Open Stack

+1 from me for Dan's approach.

On 08/09/2012 09:21 PM, Salvatore Orlando wrote:
> 
> 
> On 9 August 2012 20:16, Dan Wendlandt <dan at nicira.com
> <mailto:dan at nicira.com>> wrote:
> 
> 
> 
>     On Thu, Aug 9, 2012 at 11:04 AM, Nachi Ueno <nachi at nttmcl.com
>     <mailto: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
>         <mailto: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
>         <mailto: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
>         <mailto: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
>         <mailto: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
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
>     -- 
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     Dan Wendlandt 
>     Nicira, Inc: www.nicira.com <http://www.nicira.com>
>     twitter: danwendlandt
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto: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
>