[openstack-dev] [nova] Possible REST API design change for get-me-a-network (2.37)
Matt Riedemann
mriedem at linux.vnet.ibm.com
Mon Aug 15 15:37:54 UTC 2016
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:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> 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
>
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?
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list