OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (TOSCA-45) Capacity Requirements and Resources Use Case and Example Discussion

    [ http://tools.oasis-open.org/issues/browse/TOSCA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34001#action_34001 ] 

Ken Zink commented on TOSCA-45:

By design, the specification would not fully describe HOW to use TOSCA - those details are relegated to the Primer.     :^)

In terms of operational semantics, Requirements are specified by service providers in the TOSCA specification(s) of their service. Capabilities are specified by service providers or, ultimately, by the cloud provider. (Cloud provider capabilities may explicitly or implicitly declared.) It is the role, in my opinion, that the cloud provider is ultimately responsible for determining that all of the requirements are satisfied for a service to be deployed - or reject the deployment.

My specific interest in this area (as expressed in my presentation to the TC and summarized in the PPT presentation) relate to the "hardware resource" requirements of a service - such things as CPU, memory, storage and network connectivity. The potential difficulty to be resolved is to express these requirements in a "portable" manner; i.e., cloud provider neutral.  Commonly used default units of expression can be defined for memory and storage in terms of bytes or gigabytes.  However, CPU requirements are a different story.  The computing capability (capacity) of a (virtual) CPU will be dependent on a number of factors - most notably the underlying computer hardware.  My proposal is that compute requirements should be specified with a "unit of expression".  One such unit cited in my presentation is "SpecInt2006Rate" - which I have found very effective for this purpose in my work.  Richard Probst has pointed out that SAP has long deemed in necessary to define their own unit of computing capability for deploying their proprietary applications (services).

To return to the operational semantics, a cloud provider - or even a third party service provider - would be able to interpret the compute requirements of a service and appropriately size the deployment container (e.g., a virtual machine) with an adequate number of processors given knowledge of the underlying environment (e.g., computer hardware) where the service is being deployed.  A service specification could include multiple compute specifications (presumable equivalent) such that the service would be deployable without change by different cloud providers depending on which "units of computing" they support in their implementation.

If I have been unclear or incomplete in my response please follow up.

If I have misspoke regarding TOSCA or the specification I invite those corrections as well. 


> Capacity Requirements and Resources Use Case and Example Discussion 
> --------------------------------------------------------------------
>                 Key: TOSCA-45
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-45
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Sub-task
>          Components: Primer 
>            Reporter: Ken Zink
>            Assignee: Ken Zink
> Capacity specifications for components will be required for deployment and operations.  These specifications will utilize facilities (and probably extensions to) Requirements and Capabilities.
> A presentation will be provided with initial thoughts and direction.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]