Hi Karen,
It was a pleasure chatting with you last Friday. As we mentioned at that time, the TOSCA TC has finished its review of comments contributed to the 30-Day Public Review. As per OASIS policy, a document summarizing all of our responses has been posted and are
available on the TC’s Kavi document repository. That said; we thank ODCA again for your comments. For your convenience, we have excerpted our responses below. Our hope is that that this will facilitate future interaction and mutually beneficial communication.
In the TOSCA TC reponse document, the TC responds generally:
Please see TOSCA TC comments on the 'ODCA Table' sheet in this spreadsheet." Also, the TOSCA TC recommends that since ODCA defines "Migration
-- At Rest" in Long Distance Workload Migration Rev 1.0b as "may also include migrating applications, services," that ODCA expand the Assumptions section on page 6 to more accurately include these capabilities, which are provided by TOSCA by added explicit
references to "Adherence to the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) specification.
Without this addition, migration as defined by ODCA would not be adequately specified. We suggest useage models that might support cloud application
and service portabiltiy also be adjusted to reflect the capabilities of TOSCA to meet ODCA definitions/taxonomy regarding application and service portability.
The TC welcomes further, specific comments. Given the current timeline and OASIS process for comments, these will most-likely be reviewed during
the development of the next version of TOSCA.
The TC also provides this table, an extended version of the table that you kindly provided below:
|
|
ODCA [Manageability | CIaaS | Services] WG
|
OASIS TOSCA
|
TOSCA TC Response
|
|
Audience
|
Cloud Consumers
|
Cloud Service Providers
|
|
|
Focus
|
Logical Cloud 'layers' - IaaS, PaaS, SaaS
|
Agnostic to Cloud Layers, applies to generic 'services'
|
|
|
Inter-operability
|
Portability & Interconnect-ability are the 2 two elements that define interoperability. Considerations for both of these as they apply to IaaS, PaaS and SaaS is explicitly called out in the usage models. Portability is understood to be
event driven.
|
A service defined using the templates can be hosted with any service provider that is TOSCA compliant or even across service providers. i.e., Vendor Agnostic definition, deployment, migration and management of services.
|
Application inter-connectability between environments is out of scope for TOSCA, which is focused on application and service portability. TOSCA maps particularly well to usage scenarios in ODCA Long Distance Workload Migration Rev 1.0b
related to Migration -- At Rest within the taxonomy and with all associated useage scenarios, although Migration -- Live could be supported in appropriately designed services and applications.
The TC also notes that since TOSCA supports orchestration standards such as BPMN, that TOSCA supports the concept of portability as event-driven as an option, but provides additional flexbility for approaches that are not event-driven, as well.
TOSCA is equally applicable to IaaS, PaaS, and SaaS service models, and is an appropriate, evolving standard for service and application portability.
|
|
|
|
|
Due to the cloud provider focus, PaaS and SaaS considerations - application portability, inter-connectability between environments are not addressed
|
|
|
Security
|
Security WG has extensive and comprehensive details
|
Security is no explicitly called out or indicated as a mandatory requirement.
|
Rather than prescribe specific security standards and architectures, the TOSCA TC believes that the TOSCA Service Template is currently compatible with all XML-based approaches relevant to cloud computing, as known today. However, since
TOSCA is a meta-language, it is indeed possible to define security requirements in TOSCA. As the scope and eco-system of TOSCA continues to mature, the TOSCA TC welcomes parties interested in the future development of specific security requirements models
expressed in the TOSCA language.
|
|
on requirements to cover possible use cases across tiers
|
The TOSCA template language is extensible enough to potentially allow security requirements to be defined (e.g.: using custom name/value pair attributes) but
|
|
|
|
The lack of explicit security focus is a gap.
|
|
Thank you again for your comments and interest in TOSCA and the work of the TOSCA Technical Committee.
Thanks,
Paul
Paul Lipton
CA Technologies
VP, Industry Standards and Open Source
Member, CA Council for Technical Excellence
Office Phone: +1 609 583-9718
Mobile: +1 267 987-6887
Email:
paul.lipton@ca.com
\
From: tosca-comment@lists.oasis-open.org [mailto:tosca-comment@lists.oasis-open.org]
On Behalf Of Keehan, Karen A
Sent: Friday, January 11, 2013 7:17 PM
To: tosca-comment@lists.oasis-open.org
Cc: Giri, Ravi A; Chet Ensign; Ryan Skipp; Spence, Catherine
Subject: [tosca-comment] ODCA feedback on TOSCA TC
The following is feedback from ODCA based on ODCA Usage Models (UMs). The comparison(s) are against the ODCA requirements in ‘Interop Across Clouds’, ‘Service Orchestration’ and ‘VM Interoperability’ documents
which can be accessed
here along with the rest of our UMs.
|
|
ODCA [Manageability | CIaaS | Services] WG
|
OASIS TOSCA
|
|
Audience
|
Cloud Consumers
|
Cloud Service Providers
|
|
Focus
|
Logical Cloud 'layers' - IaaS, PaaS, SaaS
|
Agnostic to Cloud Layers, applies to generic 'services'
|
|
Inter-operability
|
Portability & Interconnect-ability are the 2 two elements that define interoperability. Considerations for both of these as they apply to IaaS, PaaS and SaaS is explicitly called out in the usage models. Portability is understood to be
event driven.
|
A service defined using the templates can be hosted with any service provider that is TOSCA compliant or even across service providers. i.e., Vendor Agnostic definition, deployment, migration and management of services.
Due to the cloud provider focus, PaaS and SaaS considerations - application portability, inter-connectability between environments are not addressed
|
|
Security
|
Security WG has extensive and comprehensive details
on requirements to cover possible use cases across tiers
|
Security is no explicitly called out or indicated as a mandatory requirement.
The TOSCA template language is extensible enough to potentially allow security requirements to be defined (e.g.: using custom name/value pair attributes) but
The lack of explicit security focus is a gap.
|
|
Tiers
|
There are specific service tiers defined - Bronze, Silver, Gold
and Platinum
|
There are no tier definitions, but requirements (and capabilities) that align to the ODCA service tiers can technically be captured in the template that is used to define the service and it's components.
It would be useful to consider Bronze / Silver / Gold / Platinum impacts here
– there isn’t a
“One size fits all in this space”, especially when, public, private and hybrid models are in context of the rest of the interoperability
|
|
Service Catalog
|
ODCA has the definition of a service catalog which can be used to 'discover' services and their capabilities and serve as a broker across cloud service providers
The model seems to have a direct Cloud to Cloud relationship, whereas ODCA see the need for an intermediate Service Catalogue
– very seldom will 2 Cloud Providers directly expose their direct Cloud environments
– they would have API’s but these would use a Service Catalogue for brokering between Cloud, and this seems to be missing from the concept
It would appear a catalogue would have to be created per node, with commercial, service and technical capabilities described
– a more effective way is a central catalogue mapping all the node capabilities and topologies and dependencies, making maintenance and control of publishing easier
|
The concept of a service catalog is not called out explicitly but the service template itself can be part of the catalog and the standardization allows easier discovery of the service and it's capabilities as well as automated mapping to
expected requirements.
But, very few organization would be amenable to allowing full XML service template definitions to be available for 'discovery' - so this is limited due to security concerns
The language constructs do allow inheritance of requirements, capabilities, states and interfaces using the DerivedFrom attribute, so needing to specify a service catalog per node can be avoided
|
|
Use Cases
|
There is extensive documentation of a broad range of use cases from a cloud consumer point of view and the requirements for each of them is also captured
|
The major use cases (cloud provider specific) for TOSCA are:
1. Services as marketable entities - standardized service templates as a means of creating a 'marketplace' for 'interoperable' IT services
2.
Portability of Service Templates - Portability of a 'service' means that the service definition can be understood across vendors. i.e., service templates defining the structure and orchestration created by one vendor (service provider)
can be parsed/understood by any other vendor that is 'TOSCA compliant'.
3.
Service Composition - allows vendor agnostic composition of service. i.e., components for a service could be from any vendor and are replaceable using the service template as a layer of abstraction for vendor selection flexibility
4.
Relation to Virtual Images -the service templates allow composition of service from various virtualization technologies, or a combination of them.
|
|
Language Considerations
|
ODCA prefers RESTful interfaces / web services
|
|
Kind Regards,
Karen Keehan
Intel Corporation
| Director, Industry Collaborations, Open Data Center Alliance
(ODCA)
| 303-513-1703 mobile
| 303-993-4740 office
|