[openstack-dev] [nova] placement/resource providers update 4
cdent+os at anticdent.org
Tue Dec 6 15:56:14 UTC 2016
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 .
> 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
> 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
More information about the OpenStack-dev