Open Stack

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.

Best,
-jay

Thanks,
-jay

[1] https://review.openstack.org/#/c/408285/
[2] https://review.openstack.org/#/c/386242/