Instance Model for TOSCA Version 1

[Pages:38]Instance Model for TOSCA Version 1.0

Committee Specification Draft 01

16 November 2017

Specification URIs

This version: (Authoritative)

Previous version: N/A

Latest version: (Authoritative)

Technical Committee: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Chairs: Paul Lipton (paul.lipton@), CA Technologies John Crandall (jcrandal@), Brocade Communications Systems

Editor: Derek Palma (dpalma@), Vnomic

Related work: This specification is related to:

? Topology and Orchestration Specification for Cloud Applications Version 1.0. Edited by Derek Palma and Thomas Spatzier. 25 November 2013. OASIS Standard. .

Abstract: This specification defines the information model, behavioral semantics, and access methods for a dynamic object model representation of TOSCA Service Template deployments required to enable on-going automated management of TOSCA topologies. The Instance Model represents the current state of a deployment including all inputs, concrete node fulfillments, property settings, cardinalities, relationships, applied policies, and correlation with external resources and entities. Service template deployments can be queried, navigated, reasoned over and updated with imperative workflows, policy actions, and their evolution observed over time. The instance model is extensible, allowing integration of information from other domains, across deployments and orchestrators.

Status: This document was last revised or approved by the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC on the above date. The level of approval is also

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 1 of 38

listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at .

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at .

This Committee Specification Draft is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page ().

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format: When referencing this specification the following citation format should be used:

[TOSCA-Instance-Model-v1.0]

Instance Model for TOSCA Version 1.0. Edited by Derek Palma. 16 November 2017. OASIS Committee Specification Draft 01. . Latest version: .

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 2 of 38

Notices

Copyright ? OASIS Open 2017. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see for above guidance.

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 3 of 38

Table of Contents

1 Introduction ........................................................................................................................................... 7 1.0 IPR Policy ........................................................................................................................................... 7 1.1 Terminology ........................................................................................................................................ 7 1.2 Normative References ........................................................................................................................ 8 1.3 Glossary.............................................................................................................................................. 8

2 Summary of key TOSCA concepts..................................................................................................... 10 3 TOSCA Instance Model Conceptual Overview .................................................................................. 11

3.1 What is an instance model?.............................................................................................................. 11 3.2 What problems does it address? ...................................................................................................... 11 4 Design Considerations ....................................................................................................................... 12 4.1 State-based Orchestration Paradigm ............................................................................................... 12 4.2 Instance Model Consumers .............................................................................................................. 12

4.2.1 Declarative Orchestration .......................................................................................................... 12 4.2.2 Workflow Execution ................................................................................................................... 12 4.2.3 External Clients ......................................................................................................................... 12 4.3 Orchestrator States vs. Real-world States ....................................................................................... 13 4.4 Reflecting Node Status in the Instance Model.................................................................................. 13 4.5 Tracking State Changes ................................................................................................................... 13 4.6 Visibility of Nodes and Node Attributes ............................................................................................ 13 4.7 Orchestration Execution Status ........................................................................................................ 14 5 Model Structure .................................................................................................................................. 15 5.1 Meta Levels....................................................................................................................................... 15 5.2 Deriving the Instance Model ............................................................................................................. 16 5.3 Sample Service Template................................................................................................................. 16 5.4 Deriving the Instance Model Graph .................................................................................................. 17 5.5 Instance Model Schema ................................................................................................................... 18 5.5.1 Schema Modeling Language..................................................................................................... 18 5.5.2 Instance Model Schema............................................................................................................ 18

5.5.2.1 InstanceClass Definition ....................................................................................................................19 5.5.2.1.1 Data Types.................................................................................................................................19 5.5.2.1.2 References.................................................................................................................................19 5.5.2.1.2.1 InstanceReference ..........................................................................................................19 5.5.2.1.2.2 ExternalToscaReference ...............................................................19 5.5.2.1.2.3 Reference scope and Semantics ....................................................................................19

5.5.3 InstanceObject Definition .......................................................................................................... 20 5.6 Instance Model Definition ................................................................................................................. 20

5.6.1 InstanceNode Definition ............................................................................................................ 20 5.6.2 InstanceProperty Definition ....................................................................................................... 21 5.6.3 InstanceAttribute Definition ....................................................................................................... 22 5.6.4 InstanceCapability Definition ..................................................................................................... 22 5.6.5 InstanceRequirement Definition ................................................................................................ 22 5.6.6 InstanceGroup Definition ........................................................................................................... 23 5.6.7 InstanceMetadata Definition ...................................................................................................... 24

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 4 of 38

5.6.8 InstanceInput Definition ............................................................................................................. 24 5.6.9 InstancePolicy Definition ........................................................................................................... 24 5.6.10 InstanceOutput Definition ........................................................................................................ 25 5.7 Complete Derivation to YAML syntax (textual) ................................................................................. 25 5.8 Specific derivations ........................................................................................................................... 26 5.8.1 Entities (Graph vertices)............................................................................................................ 26

5.8.1.1 Template (from node type).................................................................................................................26 5.8.1.2 Instance (from template) ....................................................................................................................26 5.8.1.3 Instance (from type) ...........................................................................................................................26 5.8.2 Relationships (graph edges) ..................................................................................................... 26 5.8.2.1 Relation from between a pair of nodes ..............................................................................................26 5.8.2.2 Mapping M to N (by intension) ...........................................................................................................26 5.8.2.3 Explicit M to N (by extension).............................................................................................................26 5.9 Encoding of information .................................................................................................................... 26 5.10 Serialization Issues ......................................................................................................................... 26 5.11 Relationships between Node Instances ......................................................................................... 27 5.12 Recovering the Service Template .................................................................................................. 27 6 Tracking State Changes ..................................................................................................................... 28 6.1 Reflecting Node Status in the Instance Model.................................................................................. 28 6.2 Visibility of Nodes and Node Attributes ............................................................................................ 28 6.3 Orchestration Execution Status ........................................................................................................ 28 6.4 Update Concurrency......................................................................................................................... 28 7 Query and Navigation......................................................................................................................... 29 7.1 Imperative Workflow Use Case ........................................................................................................ 29 7.2 Imperative interaction with the Instance Model ................................................................................ 29 7.3 State tracking/synchronization.......................................................................................................... 29 7.4 Query ................................................................................................................................................ 29 7.5 Navigation ......................................................................................................................................... 29 8 Extensibility......................................................................................................................................... 30 8.1 Resource Metadata .......................................................................................................................... 30 8.2 Event Triggered Updates .................................................................................................................. 30 9 Instance Model Access ...................................................................................................................... 31 9.1 YAML Dump...................................................................................................................................... 31 9.2 Instance Model Access via API ........................................................................................................ 31 10 Security Considerations ..................................................................................................................... 32 10.1 Access Control................................................................................................................................ 32 10.2 Authorization ................................................................................................................................... 32 10.3 Obfuscation of Sensitive Information .............................................................................................. 32 11 Conformance ...................................................................................................................................... 33 11.1 Conformance Clause 1: Deployment Orchestration Only .............................................................. 33 11.2 Conformance Clause 2: Post Orchestration Instance Model Snapshots ....................................... 33 11.3 Conformance Clause 3: Dynamic and Extensible Instance Model Updates .................................. 33 11.4 Conformance Clause 4: Programmatic Read-Only Access ........................................................... 33 11.5 Conformance Clause 5: Programmatic Updates ............................................................................ 33 Appendix A. Acknowledgments .................................................................................................................. 34 Appendix B. Schema Modeling Language.................................................................................................. 35

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 5 of 38

11.6 Collections ...................................................................................................................................... 36 11.7 TOSCA DSL Entity References ...................................................................................................... 36

11.7.1 ToscaDslRef Definition ............................................................................................................ 36 11.8 Cross Instance Model Linking......................................................................................................... 37

11.8.1 URIs and Entity Identity ........................................................................................................... 37 11.8.2 Local Model Linking................................................................................................................. 37 11.8.3 Foreign Model Linking ............................................................................................................. 37 Appendix C. Revision History...................................................................................................................... 38

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 6 of 38

1 Introduction

The TOSCA Domain Specific Language (DSL), expresses a topology of entities (service template), their lifecycles, management operations and constraints. Instantiation of a TOSCA service template involves an orchestrator processing a service template, fulfilling the requirements of each node template, and orchestrating a sequence of lifecycle operations across the entities of the topology to reach an end-state prescribed by the service template. The TOSCA Instance Model expresses the complete structure and state of an instantiated service template. The existence of an instance model has been implied in other TOSCA specifications when describing the behavior semantics of a TOSCA orchestrator as it executes a service template deployment. A complete and concise specification of the Instance Model permits the continued automated management of an instantiated service template and is motivated via the following use cases:

1. Expressing the end-state reached of a TOSCA deployment by an orchestrator; 2. Expressing intermediate states as the deployment is changed by declarative or imperative

orchestration; 3. Comparing a pair of TOSCA deployments, possibly by different orchestrators, for similarities or

differences; 4. Enabling imperative workflows to examine and synchronize its knowledge of the state of the

deployment; 5. Enabling imperative workflows to execute side-effects on the deployment; 6. Enabling declarative actions to be triggered as the deployment changes; 7. Expressing the state of the deployment over time, as entities in the topology change state due

to their innate behaviors and external influences; 8. Correlating entities in the deployment to entities in the physical world.

A set of Instance Model operations are defined and specified to support the creation and dynamic evolution:

1. Derivation the Instance Model from a service template 2. Accessing the Instance Model 3. Updating the Instance Model 4. Correlation of the Instance Model entities with external entities 5. Synchronizing the Instance Model with external state

1.0 IPR Policy

This Committee Specification Draft is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page ().

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 7 of 38

1.2 Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. .

1.3 Glossary

The following terms are used throughout this specification and have the following definitions when used in context of this document.

Term

Definition

Instance Model

A deployed service is a running instance of a Service Template. More precisely, the instance is derived by instantiating the Topology Template of its Service Template, most often by running a special plan defined for the Service Template, often referred to as build plan.

Node Template

A Node Template specifies the occurrence of a software component node as part of a Topology Template. Each Node Template refers to a Node Type that defines the semantics of the node (e.g., properties, attributes, requirements, capabilities, interfaces). Node Types are defined separately for reuse purposes.

Relationship Template

Service Template

A Relationship Template specifies the occurrence of a relationship between nodes in a Topology Template. Each Relationship Template refers to a Relationship Type that defines the semantics relationship (e.g., properties, attributes, interfaces). Relationship Types are defined separately for reuse purposes.

A Service Template is typically used to specify the "topology" (or structure) and "orchestration" (or invocation of management behavior) of IT services so that they can be provisioned and managed in accordance with constraints and policies.

Topology Model

Topology Template

Specifically, TOSCA Service Templates optionally allow definitions of a TOSCA Topology Template, TOSCA types (e.g., Node, Relationship, Capability, Artifact), groupings, policies and constraints along with any input or output declarations.

The term Topology Model is often used synonymously with the term Topology Template with the use of "model" being prevalent when considering a Service Template's topology definition as an abstract representation of an application or service to facilitate understanding of its functional components and by eliminating unnecessary details.

A Topology Template defines the structure of a service in the context of a Service Template. A Topology Template consists of a set of Node Template and Relationship Template definitions that together define the topology model of a service as a (not necessarily connected) directed graph.

The term Topology Template is often used synonymously with the term Topology Model. The distinction is that a topology template can be used to instantiate and orchestrate the model as a reusable pattern and includes all details necessary to accomplish it.

TOSCA-Instance-Model-v1.0-csd01

Standards Track Work Product

Copyright ? OASIS Open 2017. All Rights Reserved.

16 November 2017 Page 8 of 38

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download