OASIS TOSCA - OpenStack · PDF fileOASIS TOSCA and how it could fit into OpenStack Heat OpenStack thDesign Summit, April 15 2013 Thomas Spatzier, IBM ([email protected])

OASIS TOSCA

… and how it could fit into OpenStack Heat

OpenStack Design Summit, April 15th 2013

Thomas Spatzier, IBM ([email protected])

Agenda

• TOSCA Overview and Examples

• TOSCA Concepts Explained

• About Encoding …

• Discussion: TOSCA and Heat

2

Definition of building blocks for services

… along with the implementation artifacts for manageability operations

… and the definition of deployment artifacts for components

… including the definition of plans for orchestrating the application

What is TOSCA?

Service Template

Pro

per

ties

Interfaces

Node Types

Requirements

Capabilities

Topology and Orchestration Specification for Cloud Applications

Topology Template

Relationship Template

Node Template

type for

Cloud Service ARchive (CSAR)

----- ----- ----- -----

----- ----- ----- -----

Scripts

Installables

Images

A language for defining Service Templates …

… including a Topology Template describing the structure of a service

Packaging format (CSAR) for packaging models and all related artifacts.

3

Interfaces

Pro

per

ties

Relationship Types Plans

Definition of possible links between components

type for

TOSCA TC Members

4

3M ActiveState Axway CA Technologies CenturyLink Cisco Citrix Cloudsoft EMC Fujitsu Google HP IBM Huawei Jericho Systems NetApp Nokia Siemens Pricewaterhouse Primeton Red Hat SAP Software AG VCE Vnomic WSO2 Zenoss

1st Interop Example: SugarCRM

5

SugarCRMApp

[WebApplication]

SugarCRMDB

[MySQLDatabase]

PHPModule

[ApacheModule]

Apache

[ApacheWebServer]

MySQL

[MySQL]

connects to

hosted on

hosted on hosted on

hosted on

installed on

depends on

Server4WebTier

[Server]

Server4DBTier

[Server]

hosted on hosted on

LinuxOS4Web

[OperatingSystem]

LinuxOS4DB

[OperatingSystem]

Using TOSCA to model Applications

6

Deployment Artifact Node Type

R

C

Implementation Artifact

Lan

guag

e

TOSC

A v

1.0

sp

ec

Relationship Type

…

“Orchestrator” Deployed Instances

SugarCRMDB [MySQLDatabase]

R

C

MySQL [MySQL]

R

C

SugarCRMApp [WebApplication]

R

R

Tem

pla

tes

Properties: DB Name: “mysqldb” …

Properties: Admin User: myadmin …

Properties: Context root: /mycrm …

Properties: HTTP Port: 8080 …

Apache [ApacheWebServer]

R

C

start.sh

MySQL Database

R

C

start.sh

RPMs: mysql

mysql-server

configure.sh

MySQLDBConnection Typ

es

MySQLDBContainer Req. LinuxOS Req.

MySQL

R

C

Primary focus for users

Role of Relationships in Model Processing

7

NodeType “Database”

C NodeType

“Application” R

Lifecycle operations (create, configure, start, …) are used by an orchestrator to create

and manage components

Connector concept Relationship Types declare what endpoints they can

connect, and which processing logic they inject to

establish a link at runtime

Base Relationship Types HostedOn, DependsOn and ConnectsTo define the base

semantics for processing topology models

RelationshipType “DBConnection”

NodeTemplate “MyDB”

C NodeTemplate

“MyApp” R

is of type is of type is of type

• Use defined lifecycle operations to deploy and manage each component • If a component is related to another component, see if relationship

injects additional processing logic (e.g. pre-configure endpoint) • Use base relationship types to derive processing order

• Process a host before a hosted component (HostedOn) • Process a provider before a client (DependsOn, ConnectsTo)

… a pretty mechanical process

How is a Topology processed? • Use base relationship types to derive component

processing order – First process a host, then process hosted component – First process a component that another component

depends on, then process the dependent component – First process a component that another component

connects to, then process the connecting component

• For each component – Deploy its Deployment Artifacts – Invoke lifecycle operations in right sequence (create,

configure, start …); their can be no-ops

• If a relationship contributes logic, inject it into component operation invocations

8

Web 1

Web 2

Web 3

Web 4

Web 5

DB 1

DB 2

DB 3

DB 4

relationship injects logic

DB 1

DB 2

DB 3

DB 4

Web 1

Web 2

Web 3

Web 4

create VM

perform base OS config

install and configure httpd

install and configure php runtime

create VM

perform base OS config

install and configure MySQL

create and configure SugarCRM database

Web 5 install and configure SugarCRM app, configure database endpoint properties

run in parallel

wait for step “DB 4” to complete

Some Application

Co

mp

ute

Sto

rage

arch = x86_64 cpus = 2

mem >= 4GB OS = Linux

size >= 10GB

Database

provider = MySQL version >= 5.5

Requirements & Capabilities

9

Database Provider

Database

Co

mp

ute

Sto

rage

Requirements can be fulfilled explicitly by other components in the model

Requirements can be fulfilled by the runtime

Requirements/Capabilities are base for substitutability

Some Component

R

Provider A

C

Provider B

C

Provider C

C

OR OR

Some Application

Co

mp

ute

Sto

rage

arch = x86_64 cpus = 2

mem >= 4GB OS = Linux

size >= 10GB

Database

provider = MySQL version >= 5.5

Model Composition

10

Node Template

Node Template

Service Template 1

Service Template 2

boundary definitions

Subsystems can be abstracted in some models.

Other models can define details of subsystems.

separation of concern, re-use

Usage Scenarios for Model Composition & Substitution

11

Load Balancer

VM

Web Server

VM

1..*

Web Server

VM

Single node web tier Scalable web tier

WebApp

WebTier

App DB

Tomcat MySQL

VM VM

Network Storage

Application Layer

Platform Layer

Infrastructure Layer

Custom workload

Multiple options of

middleware deployments

Multiple options of

infrastructure configurations

Varying deployment options Layering of models

About Encoding …

12

TOSCA is XML

The TOSCA TC decided to use XML and XML Schema as the normative way for defining the TOSCA language. But: The important thing about TOSCA are the concepts, not the encoding. Alternative encodings (e.g. JSON) can be defined as part of TOSCA vNext work.

Alternative Encoding Example

13

<xs:schema ...>

<xs:element name="ServerProperties" type="tServerProperties"/>

<xs:complexType name="tServerProperties">

<xs:sequence>

<xs:element name="NumCpus" default="1">

<xs:simpleType>

<xs:restriction base="xs:int">

<xs:enumeration value="1"/>



</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="Memory" type="xs:int"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

<NodeType name="Server">

<PropertiesDefinition element="tbase:ServerProperties"/>

…

</NodeType>

<TopologyTemplate>

<NodeTemplate id=“MyServer" type="tbase:Server">

<Properties>

<tbase:ServerProperties>

<NumCpus>2</NumCpus>

<Memory>4096</Memory>

</tbase:ServerProperties>

</Properties>

...

</NodeTemplate>

...

</TopologyTemplate>

"NodeType" : {

"name" : "Server",

"properties" : [

{

"name" : "NumpCpus",

"type" : "integer",

"options" : [1 ,2, 4]

},

{

"name" : "Memory",

"type" : "integer",

}

]

...

}

"TopologyTemplate" : {

"NodeTemplates" : [

{

"id" : "MyServer",

"type" : "Server",

"properties" : [

"NumCpus" : 2,

"Memory" : 4096

]

},

...

],

...

}

Now, how could it fit into Heat?

• It’s all about concepts: as longs as a pattern engine’s concepts and TOSCA are aligned, mapping to TOSCA as an external format is straight forward – No need to use TOSCA as Heat’s core format

• Define a sub-set profile of TOSCA that is appropriate for use cases targeted

by Heat • Define an alternative JSON rendering for TOSCA sub-set profile • Define a set of base Node- and Relationship Types for core OpenStack

resources: Compute (Nova), Network (Quantum), Block Storage (Cinder), Object Storage (Swift) – As natively supported types – Users do not have to care about defining TOSCA types, but can just start

defining templates

• Use implementation to improve and refine the TOSCA standard; use standardized concepts to shape implementation

14

Learn more about TOSCA

• TOSCA Specification, Version 1.0 Committee Specification 01, 18 March November 2013, http://docs.oasis-open.org/tosca/TOSCA/v1.0/cs01/TOSCA-v1.0-cs01.pdf

• TOSCA Primer, Version 1.0 Committee Note Draft (CND) 01, Public Review Draft 01, 31 January 2013, http://docs.oasis-open.org/tosca/tosca-primer/v1.0/cnd01/tosca-primer-v1.0-cnd01.pdf

• TOSCA Implementer's Recommendations for Interoperable TOSCA

Implementations, Version 1.0 Interoperability Subcommittee, Working Draft 01, Rev. 02, 14 January 2013, http://www.oasis-open.org/committees/document.php?document_id=47888&wg_abbrev=tosca-interop

• TOSCA Interoperability Subcommittee, SugarCRM Scenario Sample CSAR

Preliminary Draft CSAR for Interop. Testing against TOSCA v1.0 Specification, http://www.oasis-open.org/committees/document.php?document_id=47585&wg_abbrev=tosca-interop

15

Documents

OASIS TOSCA - OpenStack · PDF fileOASIS TOSCA and how it could fit into OpenStack Heat OpenStack thDesign Summit, April 15 2013 Thomas Spatzier, IBM ([email protected])