Open Stack

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:
>>> 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?
>

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