Open Stack

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.  Otherwise, "" means
different things depending on the parameter (since its value to send in ""
to mean the empty string for fields like name).

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?

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120809/52415c5d/attachment-0001.html>