1. Proposal by CA Technologies, IBM, SAP, Vnomic
Using TOSCA Requirements /Capabilities to Specify Capacity Resources (Primer Considerations)
Proposal by CA Technologies, IBM, SAP, Vnomic

2. Resource Types Common (Capacity and Consumption) Other
CPU capacity (in portable units such as SPECint2006_rate)
Memory (virtual or physical)
Storage (local disk, SAN, NAS)
Bandwidth (network)
Other
Workload types, Abstract resources
Constraints in environment and other elements

3. Typical Use Case Typical use case Resources of a Service
Specify the resources, capabilities and their characteristics to (re)deploy a service in a cloud environment (see supplemental section)
Can be effectively expressed using proposed requirements/capabilities framework
Resources of a Service
Sum of all included elements in that service (per resource type)

4. Specifying Resource Requirements
Definitions needed
CapabilityType(s) for resources such as Memory, CPU, Storage, etc.
NodeType(s) and NodeTemplate(s) to express requirements against the hosting resources
May be specified as ‘hints’ or requirements
Number and types of nodes are implementation dependent
Single, multiple locations, availability zones, …
Need to define semantics

5. Resources as Capabilities
Predefined by TOSCA
<NodeTemplate id="uid-host" nodeType="tcore:Host"> <Capabilities> <Capability is="uid-resources-memory" name="myMemory"> <Properties> <Memory>128</Memory> </Properties> </Capability> <Capability id="uid-resources-compute" name="myCompute"> <SpecInt2006Rate>100</SpecInt2006Rate> <CPU_MHZ>4</CPU_MHZ> <NCPU>64</NCPU> <Capability id="uid-resources-storage-SAN" name="myStorage"> <Storage>5000</Storage> <Luns>10</Luns> </Capabilities> </NodeTemplate>
Unit is defined in CapabilityType for Memory
Max capabilities for Node
Multiple properties per Capability

6. Resources Requirements
Defined by Capability
<Requirements> <Requirement ref="uid-resources-memory“ name=“memory1> <Properties> <Memory lowerBound="4" upperBound="16" typical=”8”/> </Properties> </Requirement> <Requirement req="uid-resources-compute“ name=“CPU1”> <SpecInt2006Rate lowerBound="10" /> <Requirement ref="uid-resources-storage-SAN“ name=“storage1> <Storage lowerBound="100" upperBound="200" /> <Luns lowerBound="1" /> </Requirements>
For better matching
Multiple property match

7. Remaining Comments and Where we Left Them

8. Remaining Comments & Suggestions
Requirement definitions should support Unit & Type to accommodate capability type of resources such as CPU & memory.
Agreed, needs specifics

9. Remaining Comments & Suggestions 2
Consider requirement phases
Initial requirements
Needed before a node can be instantiated
Operational requirements
Needed to satisfy changing demands; scaling up/down
Example:
<Requirements type=”initiation”>
Agreed. Needs further discussion

10. Remaining Comments & Suggestions 3
The Requirement to Capability matching needs to be further defined or extended
How will one express a requirement of
Tomcat version 5.0 and above?
Need for a SQL92 compliant database Server?
Need to define additional semantics
Could possibly borrow subset of OASIS SDD
A more detailed proposal is needed

11. Examples of Property Syntax and Matching Requirements
Type + Property syntax to match:
Exact value: property A must be ‘X’
One of enumerated value: property A must be 1 or 5
In range (min, max): property A must be between 1 and 10
Regex match: property A should match 5.* (* is wild character) or string ‘5.*’
More complex expressions: Composite, hints/recommendations, “relaxed matching”, …

12. Supplemental Material

13. Use Case Description Use Case Specification of Resource Requirements
TOSCA-00
Specification of Resource Requirements
Description:
Specify the resources required to (re)deploy a service successfully in a cloud environment.
Desired outcome:
Any service deployed using the TOSCA specification would be provisioned with sufficient physical and virtual resources to meet its resource demands while avoiding excessive resource cost.
Triggering business event(s)
Deployment of a new or existing service into a Cloud environment.
Actor(s):
The service owners and Cloud Providers.
Involved components and services
Virtual and physical resource management software (e.g., vCenter in a VMware environment), load testing software, resource measurement software, environment-independent resource capacity analysis software, workload forecasting software.
Dependencies (pre-conditions):
Performance modeling and analysis of the service under anticipated workload volumes, perhaps on a different cloud provider.
Related Use Cases
Service Monitoring Use Case

14. Preferred Initial Process Flow
Step Description
Data and Software Required
Service developer or performance analyst load tests the application in a test environment (or for redeployment obtains monitoring information from a monitoring environment)
Software: Load test and resource measurement (or monitoring in the case of redeployment)
Performance analyst models environment- independent service resource requirements as a function of workload volumes in the service’s TOSCA Service Template.
Resource requirements are generated by the tools or by the analyst
Data: Load test or production monitoring transaction volumes, resource consumption measurements and resource configurations
Software: Environment- independent resource capacity analysis software
Service owner deploys application with TOSCA Service Template that includes environment- independent resource requirements to Cloud provider
Note: This step is repeated with each new version of the service to be deployed
The Cloud Provider’s TOSCA container deploys the service in accordance with the TOSCA Service Template, including the provisioning of the service’s required resources

15. Preferred Ongoing Process Flow
Service owner periodically forecasts future workload volumes and models changing requirements in updated version of the TOSCA Service Template. The service owner provides updated template to the Cloud Provider.
Data: Historical and forecasted business and IT workload data
Software: Workload forecasting software
Cloud Provider (or service owner) adjusts the service’s resources in accordance with the new workload volume forecasts and requirements specified in the TOSCA Service Template.

16. Error Flow and Variations
Based on user request and Cloud Provider options, the CP rejects the request if not enough resources are available to satisfy request, or the request is queued until enough resources are available.
Variations:
Cloud I(P)aaS provider periodically optimizes the deployment of (or re-deploys) all service components from all cloud tenants according to forecasted workload volumes and as modeled in updated TOSCA Service Templates.
Software required: Cloud optimization software that supports TOSCA
Additional Information:
Determining appropriate resource configurations for service components in new execution environments is difficult because of the wide range and non-linearity of resource capacity and scalability (resource effectiveness as a function of the resources allocated). The process specified above addresses this problem.
Design Suggestions:

17. OASIS SDD (Solution Deployment Descriptor)
SDD v1.0 is an OASIS standard (as of 2008)
Limited update? Suitability? What can we learn/borrow?
Example:

18. SDD Semantics - 1 CapacityConstraint ConsumptionConstraint
Constraints on the available capacity of a particular property of a particular resource. Ex: CPU speed
ConsumptionConstraint
Constraints on the quantity of a particular property of a specific resource that is available for consumption. Ex: disk space
PropertyConstraint
A specific resource properties must have a specific value or set of values. Ex: OS=Linux
VersionConstraint
Constraint on the version of a specific resource. Ex: Version=1.1, MinVersion=1.0
This can be expressed using Capability/Requirement Type + constraints

19. SDD Semantics - 2 This needs further discussion UniquenessConstraint
When two resources defined in topology MUST or MUST NOT resolve to the same resource instance during a particular deployment
RelationshipConstraint
Constraint on a particular relationship between resources
AuthorizationConstraint
A required level of authorization required by a resource in order to deploy the content
This needs further discussion