Open Stack

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 <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.

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev