Open Stack

On 12/06/2016 04:00 PM, melanie witt wrote:
> On Tue, 6 Dec 2016 15:42:18 -0500, Jay Pipes wrote:
>> On 12/06/2016 03:28 PM, Ed Leafe wrote:
>>> On Dec 6, 2016, at 2:16 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>
>>>> 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
>>>
>>> OK, that’s fine. The URI path is still just 126 characters, well below
>>> the limit of around 8K. It still seems anything but scary.
>>
>> Oh, absolutely, I wasn't arguing about length of URI or anything.
>>
>> To be clear, I could either go the above route or even do a POST
>> /resource_providers that returns a list of resource providers instead of
>> creating a resource provider. Don't mind either way.
>>
>> But, we should definitely agree on which this is going to be ASAP.
>
> Last time I was aware of the discussion, I thought that sophisticated
> queries for a list of resource providers would involve specifying a
> structured JSON payload. That is where I don't tend to think a query
> string in the URI is so usable. Are we assuming user queries will be
> relatively simple?
>
> From what I recall, the ideas were:
>
> 1. GET with non-JSON query string if simple, else GET with JSON body
> (which is not covered by HTTP spec)
>
> 2. GET with JSON query string to cover both simple and sophisticated
> queries
>
> 3. POST with JSON body to a /resource_providers/list URI to cover both
> simple and sophisticated queries
>
> Which option are we talking about now? 1? Or a version of it where
> queries are assumed to be simple and no JSON structure at all?

We're discussing only doing:

  GET /resource_providers?<simple non-JSON query params>

Once we start doing claims in the scheduler, we'll have the ability to do:

  POST /allocations
  {
     <more complex JSON body specifying requested resources, traits, and 
all kinds of stuff :)>
  }

Best,
-jay