Open Stack

Le 08/12/2016 02:28, Jay Pipes a écrit :
> On 12/07/2016 07:06 PM, Matt Riedemann wrote:
>> On 12/7/2016 2:40 AM, Sylvain Bauza wrote:
>>>
>>> FWIW, I think POST is not that complex and allows us to have room for
>>> further request information like traits, without defeating the purpose
>>> to have something RESTful.
>>>
>>> The proposal is up, comments welcome
>>> https://review.openstack.org/#/c/392569/
>>>
>>> -Sylvain
>>>
>>
>> Just to update everyone else following along, we had a discussion in IRC
>> today (me, edleafe, bauzas, sdague, cdent and dansmith) about GET vs
>> POST and the majority of us sided with simple GETs for now, knowing we
>> have the option to do complex POST requests later with a microversion if
>> it turns out that we need it.
>>
>> I was originally wanting to do the POST request but wasn't fully aware
>> of the future plans to POST to /allocations to make claims with a
>> request spec which can have a complicated request body.
>>
>> We also aren't doing traits right now, so while I'm not crazy about the
>> namespaced query language that's going to get built into the GET query
>> parameters, right now it's not a monster we need to deal with.
>>
>> I don't want to underestimate the complexity that might blow up the GET
>> query parameter schema, especially once we start having to deal with NFV
>> use cases, but we aren't there yet and I'd rather not boil the ocean
>> right now. Sean pointed out, as thankfully he usually does, that if we
>> over-complicate this for future requirements we'll lose time working on
>> what needs to get done for the majority of use cases that we want to
>> have working in Ocata, so let's move forward with the more normal GET
>> format for listing resource providers with filters knowing that we have
>> options in the future with POST and microversions if we need that escape
>> hatch.
> 
> Thanks for posting back on this. I just finished reading back through
> the (long) conversation had on IRC this afternoon. Appreciate everyone
> lending their opinions, sticking to the discussion, and pushing through
> to a decision/conclusion.
> 
> At the end of the day, nobody is ever completely happy with every
> solution that is proposed. That's just the way it is with things like
> this. I know Dan and Sylvain aren't pleased with the decision, but I
> appreciate that both of you stuck with it and kept the discussion civil
> and productive.
> 
> As others noted, I pushed up code that implements the GET
> /resource_providers?resources=XXX handling [1]. It is rebased off of
> Sylvain's patch that adds object-layer handling of resource filters [2].
> Hope to see your reviews on that. Sylvain, not sure there is anything to
> merge/squash in the patch, but if there is, I'll chat with you about it
> tomorrow morning.
> 

Sorry, but since I worked on the API for 4 weeks, I'd prefer to use my
own change and adding you as a Co-Author.

Anyway, thanks for uploading it.

-Sylvain


> Best,
> -jay
> 
> Thanks,
> -jay
> 
> [1] https://review.openstack.org/#/c/408285/
> [2] https://review.openstack.org/#/c/386242/
> 
> __________________________________________________________________________
> 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