Open Stack

2016-08-11 14:53 GMT-07:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:
> I wanted to bring this up for awareness since we're getting close to feature
> freeze and want consensus before it gets too late.
>
> Ken'ichi brought up a good question on my REST API change for the 2.37
> microversion:
>
> https://review.openstack.org/#/c/316398/
>
> The way I had written this was to just add special auto/none values for the
> networks 'uuid' field in the server create request schema.
>
> The catch with using auto/none is that they can't be specified with any
> other values, like other networks, or a port, or really anything else. It's
> just a list with a single entry and that's either uuid=auto or uuid=none.
>
> Ken'ichi's point was, why not just make "networks" in this case map to
> 'auto' or 'none' or the list that exists today.
>
> I like the idea, it's cleaner and it probably allows moving some of the
> validation from the REST API code into the json schema (I think, not totally
> sure about that yet).

Yeah, that also is a nice point.
Current json-schema [1] shows "uuid" parameter accepts not only
uuid-format string but also 'auto' and 'none'.
That seems fair from the naming.

> It is a change for how networks are requested today so there would be some
> conditional logic change pushed on the client - my tempest test change and
> novaclient changes would have to be updated for sure.

You have already work so much for this feature and client
implementation including Tempest.
Sorry for pointing this out lately, but after implementing, it is more
harder to change.
It is nice to avoid more microversions if we can.

Thanks
Ken Omichi

---
[1]: https://review.openstack.org/#/c/316398/35/nova/api/openstack/compute/schemas/servers.py


> So I'm looking for input on that idea before we get too late, is that
> difference worth the work and syntax change in how the client requests a
> network when creating a server?
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev