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 <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
