On Fri, 2 Dec 2016, Matt Riedemann wrote:
Some responses within to clarify a few points.
On 12/2/2016 12:04 PM, Chris Dent wrote:
There are some things to consider as that work progresses:
* The bit about aggregates in the previous section: the list of
returned resource providers needs to include associated providers.
nit: I think you mean associated _aggregates_ here.
Not really. The only thing that can show up when doing a request to
GET /resource_providers is a resource provider. So in this case what
I meant was returning some resource providers that are associated
with another one _because of_ aggregates.
* There is unresolved debate about the structure of the request being
made to the API. Is it POST or a GET, does it have a body or use
query strings? The plan is to resolve this discussion in the review
of the code at [3].
I personally prefer the POST after reading about the differences between the
two, and when reviewing the spec on this. I'm not crazy about the scheduler
having to pass a giant json string as a query parameter to a GET request on
the placement API, I'd rather do that with a request body.
I think the giant json package (wherever it may reside) will only
become a thing when we are doing actual claims via the /allocations
endpoint, in which case a POST will be the right thing (since we're
doing a right). The query against /resource_providers is merely to
limit a large list of resource providers to a smaller list of
resource providers, based on a relatively small number of
parameters.
Honestly I skimmed this part because I'm mostly concerned with immediate
priorities, but understand if you need to do a brain dump for posterity and
tire kicking.
Yeah, this is mostly just to make sure that we have some idea of
what's on the radar and whether we're being remotely realistic.
--
Chris Dent ¯\_(ツ)_/¯ https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
