Open Stack

On 07/31/2016 10:03 PM, Alex Xu wrote:
> 2016-07-28 22:31 GMT+08:00 Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>>:
>
>     On 07/20/2016 11:25 PM, Alex Xu wrote:
>
>         One more for end users: Capabilities Discovery API, it should be
>         'GET
>         /resource_providers/tags'. Or a proxy API from nova to the placement
>         API....?
>
>
>     I would imagine that it should be a `GET
>     /resource-providers/{uuid}/capabilities` call on the placement API,
>     only visible to cloud administrators.
>
> When the end-user request a capability which doesn't support by the
> cloud, the end-user needs to wait for a moment after sent boot request
> due to we use async call in nova, then he get an instance with error
> status. The error info is no valid host. If this is the only way for
> user to discover the capabilities in the cloud, that sounds bad. So we
> need an API for the end-user to discover the Capabilities which are
> supported in the cloud, the end-user can query this API before send boot
> request.

Ah, yes, totally agreed. I'm not sure if that is something that we'd 
want to put as a normal-end-user-callable API endpoint in the placement 
API, but certainly we could do something like this in the placement API:

  GET /capabilities

Would return a list of capability strings representing the distinct set 
of capabilities that any resource provider in the system exposed. It 
would not give the user any counts of resource providers that expose the 
capabilities, nor would it provide any information regarding which 
resource providers had any available inventory for a consumer to use.

Nova could then either have a proxy API call that would add the normal 
end-user interface to that information or completely hide it from end 
users via the existing flavors interface?

Thoughts?

Best,
-jay