> -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Monday, August 1, 2016 1:09 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage > Capabilities with ResourceProvider > > 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? [Mooney, Sean K] the main drawback with that as an end user is you cannot tell what combination of capabilities will Work together. For example a cloud might provide SSDs and GPUs but they may not be provided on the Same host or indeed still available on the same host though in the latter case no valid host would be the expected behavior. That said this can be somewhat mitigated via operators creating flavors that will work with their infra which is a reasonable requirement For us to ask them to fulfill but tenant could still uploads images with capability request or indeed craft boot requests that would still fail. You would basically need to return a list of capability adjacency lists so that the end user could build the matrix of what features can be requested together. That would potentially be computationally intensive in the api but mysql should be able to compute it efficiently. > > 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
