On 8/15/2016 10:37 AM, Matt Riedemann wrote:
On 8/11/2016 6:26 PM, Andrew Laski wrote:
On Thu, Aug 11, 2016, at 06:54 PM, Chris Friesen wrote:
On 08/11/2016 03:53 PM, Matt Riedemann wrote:
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).
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.
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?
I like the idea...having magic values for 'uuid' that aren't actually
uuids and
magically don't work with other parameters is sort of gross.
+1. It's cleaner and better represents what's being requested IMO.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OK, sdague agreed with the suggested new approach to make
server.networks a list or enum, so I'm working on that change this week.
I have a question still. Today you can specify a network uuid of
br-<uuid> and the REST API will strip the br- prefix. This is a
carryover from super old quantum behavior which is no longer valid with
neutron. With my 2.37 change I was killing that behavior, now I won't
technically need that anymore since I won't be going down that code path
for validation.
So should I continue to try and fix this as part of the 2.37
microversion or just leave it as-is to avoid additional complexity in
this change?
Alternatively we consider passing non-UUIDs for network IDs as a bug and
fix the schema and drop that code. Then it's not blocked on a
microversion or feature freeze schedule.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
