Open Stack

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