3.9 Query Cloud-Provider Capabilities and Capacities

****WORKING DOCUMENT****

3.9     Query Cloud-Provider Capabilities and Capacities

Actors: cloud-user, cloud-provider

Goals: A cloud-user makes a structured capability or capacity or price request to one or several cloud-providers and receives a structured response that can be used as input to drive service decisions.

Assumptions: An extensible industry request/response interface for cloud-provider capability and capacity characteristics. The capability request format will include a minimum set of named capabilities that all implementers of the standard can respond to affirmatively or negatively.  Each named capability has related specific metric parameters, for example size, speed and number of cores for an instance specification, compliance or noncompliance for a Trusted Internet Connection (TIC) specification, or block or REST interface for a storage specification.  Capability responses might include cloud-provider-specific identifiers for the returned capability to assist in subsequent capacity queries or provisioning requests.  Queries on capabilities beyond the minimum agreed set are permitted, and return an "unrecognized-capabilities" response.  The capacity request format and interface is dependent upon capability definition, with parameters such as capability of interest, and metric desired.  Examples include availability of a quantity of instance capabilities of a given size, guaranteed response time, and available storage volume for a specified storage type.  Capacity responses contain a pricing response with a time window of availability for the pricing so that cloud-users can make procurement decisions. Capacity responses do not guarantee that actual availability will continue beyond the moment of query.

Success Scenario 1 (Capability Request: IaaS, PaaS, SaaS): A cloud-user wishes to determine whether cloud-provider-1 can support a named cloud capability, for example the ability to run instances of a specified size and speed, the ability to support queuing, or the ability to supply a particular named class of storage. The cloud-user marshals a capability request using an industry-standard format, and transmits the request to cloud-provider-1 using an industry-standard request/response method and cloud-provider-1's authentication credentials. Cloud-provider-1 receives the capabilities request, evaluates it against its capabilities data and returns a structured response to the cloud-user specifying the extent to which the desired capability is available from cloud-provider-1. Responses can be affirmative, negative, or "near miss" responses containing structured variance data to assist in fallback decisions. The cloud-user evaluates the response, either through an automated program or human review, and makes an allocation decision or subsequent capacity requests for cloud-provider-1. A capability request can be repeated across multiple cloud-providers to compare capabilities at a point in time to drive service acquisition or allocation decisions.

Failure Conditions 1: (1) Network, authentication or interface difficulties cause the request to fail; (2) Cloud-provider-1 request processing fails; (3) Cloud-provider-1 is unable to recognize the named cloud capability because it is outside the minimum required capabilities.

Failure Handling 1: (1) The cloud-user observes request failure and consequent error messages and retries in the case of a transient error or remedies problem; (2) The cloud-user observes request failure and retries in the case of a transient error or contacts cloud-provider-1; (3) Cloud-provider-1 returns a specific "unrecognized capability" response indicating that the requested capability is not a recognized capability for cloud-provider-1.

Success Scenario 2 (Capacity Request: IaaS, PaaS, SaaS): A cloud-user wishes to ascertain whether cloud-provider-1 has adequate capacity to provide a named capability and the current cost of the capacity/capability pair. The cloud-user marshals a capacity request using an industry-standard format and transmits the request to cloud-provider-1 using an industry-standard request/response method and cloud-provider-1 authentication credentials. Cloud-provider-1 receives the capacity request, evaluates it against their current runtime availability data and spot pricing information, and returns a structured response to the cloud-user specifying the extent to which the desired capacity is available from cloud-provider-1, the current cost at which it is available to the requesting cloud-user, and the time window within which the capacity is available at the specified cost.  Note that the time window guarantees pricing only; actual availability is not guaranteed beyond the moment of request. The cloud-user evaluates the response, either through an automated program or human review, and makes an allocation decision for cloud-provider-1.  A capacity request can be repeated across multiple cloud-providers to compare capabilities at a point in time to drive service acquisition or allocation decisions. Often a capacity request will follow a previous capability request/response invocation and contain the cloud-provider-1 specific identifier for the affirmatively-queried capability as a parameter.

Failure Conditions 2: Include all Scenario 1: capabilities failure conditions with respect to capacities.

Failure Handling 2: Include all Scenario 1: capabilities failure handling with respect to capacities.

Success Scenario 3 (Set Request, IaaS, PaaS, SaaS): A cloud-user wishes to determine if all or part of a set of capabilities or capacities are available from cloud-provider-1.  For example, the cloud-user might request capacity for a set consisting of 20 VM's of specified capability, 500GB of block storage, 100 GB/month network bandwidth and TIC compliance.  The cloud-user marshals and sends cloud-provider-1 a capacity or capability request as discussed in previous scenarios, using an extended syntax that permits assembly of multiple capabilities or capacities into a single request.  Cloud-provider-1 evaluates the capacity or capability request's components and returns a structured response for the set which contains an overall capability or capacity response for the set containing per cent coverage of components, along with information on each component in the set.  The cloud-user receives the response and evaluates set coverage information to make an allocation or procurement decision.

Failure Conditions 3:  (1) Include all Scenario 1: capabilities failure conditions with respect to capacities; (2) Elements of capability or capacity set are not recognized by cloud-provider-1 because they fall outside the minimum required capabilities; (3) Processing failure on cloud-provider-1 fails to return a valid result for one of capability or capacity set.

Failure Handling 3:  (1) Include all Scenario 1: capabilities failure handling with respect to capacities; (2) Elements of capability or capacity set falling outside minimum required capabilities deliver an "unrecognized capability" response within the set, and are treated as "not-implemented" by the overall response; (3) Elements of capability or capacity set failing to process deliver an error response within the set and are treated as "not-implemented" by the overall response.

Requirements File:  NA

Credit: NA