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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev