Open Stack

On 12/06/2016 02:02 PM, Ed Leafe wrote:
> On Dec 6, 2016, at 9:56 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>
>>>> * 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.
>
> GET /resource_providers?DISK_GB=40&VCPU=2&MEMORY_MB=2048
>
> For the life of me I can't see what's so scary about this. Sure, we may add a few more in the future, but it's never going to grow to gigantic proportions.

I would prefer:

  GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048

to "group" the resources parameter together. When we add in trait 
lookups, we're going to want a way to clearly delineate between resource 
classes and traits other than just knowing resource classes are ALL_CAPS...

  GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
       &required=storage:ssd,hw:cpu:x86:avx2
       &preferred=virt:hyperv:gen2

Best,
-jay