University of StuttgartUniversitätsstr. 3870569 StuttgartGermany

Tim Waizenegger Gefördert durch:

Förderschwerpunkt:

Projektträger:

www.opentosca.org

How to Build CSARsfor OpenTOSCA

2

Preface

© University of Stuttgart 3

CloudCycle

Purpose of this Document

This How-To will explain the general steps involved in creating a cloud service model in TOSCA and providing itas a packaged CSAR file for OpenTOSCA

© University of Stuttgart 4

CloudCycle

Prerequisites

A running instance of the Winery modeling tool

See Installation Guide

Existing NodeTypes

See Winery Quick Start

Knowledge about the OpenTOSCA principles andimperative provisioning

See OpenTOSCA Presentation

5

Basics

© University of Stuttgart 6

CloudCycle

TOSCA in one Slide

TOSCA conceptually consists of two parts:

Application Topologies

Management Plans

Node

Application Topology

calls

Node

Management Plans

Relationship

Management Operation

X

© University of Stuttgart 7

CloudCycle

Contents of a CSAR file

Cloud Service Archive (CSAR)

X

Deployment

Artifacts

Topology

(Templates)

Management

Plans

Images

Installables

Implementa-

tion Artifacts

Services

Scripts

Types

Implementation

Artifacts

Deployment

Artifacts

Type

InterfacesProperties

8

Steps to create a CSAR

© University of Stuttgart 9

CloudCycle

Process overview

1. Sketch the topology and orchestration

2. Decide on appropriate NodeTypes for your topology

3. Create a new ServiceTemplate in Winery

4. Model your previously sketched topology in winery usingyour NodeTypes as building blocks

5. Supply the necessary parameters to the NodeTemplates

6. Model and then import your complete Plan-Package

7. Supply the input/output message format of your plan

8. Define your default plan input message and furtherselfservice information

9. Export your finished ServiceTemplate as CSAR file

© University of Stuttgart 10

CloudCycle

1. Sketch the topology and orchestration

For the purpose of this guide, we will model a cloudservice offering a MySQL Database

We will use the amazon public cloud for hosting a virtual machine

Which should run a linux operating system

On which we then run the MySQL database system

Our provisioning logic therefore needs to:

Request a virtual machine with the appropriate operatingsystem

Install the MySQL database

And finally configure the MySQL instance

© University of Stuttgart 11

CloudCycle

2. Decide on appropriate NodeTypes for your topology

Database

( MySQL )

Operating System

( Ubuntu 12.04 )

Public Cloud

( AmazonEC2 )

Amazon

EC2

VM

( VirtualMachine )Provision VM and OS

Install MySQL

I

A

I

A

I

A

Configure instance

© University of Stuttgart 12

CloudCycle

3. Create a new ServiceTemplate in Winery

© University of Stuttgart 13

CloudCycle

4. Model your topology

© University of Stuttgart 14

CloudCycle

4. Model your topology

© University of Stuttgart 15

CloudCycle

5. Supply parameters to the node templates

© University of Stuttgart 16

CloudCycle

6. Model & Import your plan package

Since OpenTOSCA is an imperative container, youneed to provide the topology AND orchestration logic

OpenTOSCA currently supports orchestration logic in the form of BPEL workflows

You can use any BPEL modeling tool (e.g. https://eclipse.org/bpel/) to develop yourorchestration plan

An example plan can be found in the example CSAR referenced on the very last slide of this document

As the next step, import the finished plan packageinto Winery

© University of Stuttgart 17

CloudCycle

6. Model & Import your plan package

© University of Stuttgart 18

CloudCycle

6. Model & Import your plan package

© University of Stuttgart 19

CloudCycle

7. Supply plan input and output parameters

The plan I/O parameters you supply to Winery will be written to the TOSCA service template definition

They have to match the input/output message definition from the plan itself

It is good practice to copy the message definition from the plan’s WSDL to the TOSCA definition

© University of Stuttgart 20

CloudCycle

8. Provide Self-Service Information

The OpenTOSCA ecosystem provides a Self-Service Portal which

Shows all CSARS available in the container with a description

Allows starting the Build Plan execution by a single click bypassing a predefined (default) plan input message to theplan

Receives the callback from the plan to show the plan resultto the user

To use this feature, you have to supply the followingas part of the CSAR:

Service description/icon

BuildPlan reference and default input message

© University of Stuttgart 21

CloudCycle

8. Provide Self-Service Information

© University of Stuttgart 22

CloudCycle

9. Export finished CSAR file

Now the finished CSAR can be exported from Winery

It can be re-imported to different Winery instances

A CSAR file is a ZIP file, it can be extracted, edited byhand and re-packaged

© University of Stuttgart 23

CloudCycle

9. Export finished CSAR file

24

Further Information

© University of Stuttgart 25

CloudCycle

A simple example CSAR file

An example CSAR file can be found at:

https://github.com/timwaizenegger/CSAR_Template.git

It contains a small topology consiting only of an OpenStackvirtual machine node and a linux operating system node The OpenStack node has an attached implementation artifact for

calling the OpenStack API from within a build plan The linux node has an attached implementation artifact that allows

sending SSH-commands to the linux-VM from within a plan

It contains an executable BPEL build plan which will provision a single virtual machine running linux, and then execute a singlecommand on that machine via SSH

It contains self-service data and can be used from the self-service portal Vinothek

It contains an ANT script for re-packaging the CSAR file after manual extraction/modification