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/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
