On Mon, Aug 1, 2016, at 08:08 AM, Jay Pipes wrote: > 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.
This is what I had imagined based on the midcycle discussion of this topic. Just information about what is possible to request, and no information about what is available. > > 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? Please no more proxy APIs :) > > 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 __________________________________________________________________________ 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