On 07/31/2016 10:03 PM, Alex Xu wrote:
2016-07-28 22:31 GMT+08:00 Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
