Open Stack

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