1. science
2. engineering

How to Build CSARs
for OpenTOSCA
University of Stuttgart
Universitätsstr. 38
70569 Stuttgart
Germany
Tim Waizenegger
Gefördert durch:
Förderschwerpunkt:
Projektträger:
www.opentosca.org
Preface
2
Purpose of this Document
CloudCycle
This How-To will explain the general steps involved in
creating a cloud service model in TOSCA and providing it
as a packaged CSAR file for OpenTOSCA
© University of Stuttgart
3
Prerequisites

A running instance of the Winery modeling tool

CloudCycle

Existing NodeTypes


See Installation Guide
See Winery Quick Start
Knowledge about the OpenTOSCA principles and
imperative provisioning

See OpenTOSCA Presentation
© University of Stuttgart
4
Basics
5
TOSCA in one Slide

TOSCA conceptually consists of two parts:
 Application Topologies
 Management Plans
Management Plans
CloudCycle
Application Topology
Node
X
Relationship
calls
Node
© University of Stuttgart
Management
Operation
6
Contents of a CSAR file
Type
CloudCycle
Properties
X
Interfaces
Types
Management
Plans
Deployment
Artifacts
Implementation Artifacts
Images
Services
Installables
Scripts
Deployment
Artifacts
Implementation
Artifacts
Topology
(Templates)
Cloud Service Archive (CSAR)
© University of Stuttgart
7
Steps to create a CSAR
8
Process overview
1.
2.
CloudCycle
3.
4.
5.
6.
7.
8.
9.
Sketch the topology and orchestration
Decide on appropriate NodeTypes for your topology
Create a new ServiceTemplate in Winery
Model your previously sketched topology in winery using
your NodeTypes as building blocks
Supply the necessary parameters to the NodeTemplates
Model and then import your complete Plan-Package
Supply the input/output message format of your plan
Define your default plan input message and further
selfservice information
Export your finished ServiceTemplate as CSAR file
© University of Stuttgart
9
1. Sketch the topology and orchestration

CloudCycle




For the purpose of this guide, we will model a cloud
service 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 operating
system
Install the MySQL database
And finally configure the MySQL instance
© University of Stuttgart
10
2. Decide on appropriate NodeTypes for your topology
Database
( MySQL )
I
A
CloudCycle
Configure instance
Operating System
( Ubuntu 12.04 )
I
A
Install MySQL
VM
( VirtualMachine )
Amazon
EC2
© University of Stuttgart
Public Cloud
( AmazonEC2 )
Provision VM and OS
I
A
11
CloudCycle
3. Create a new ServiceTemplate in Winery
© University of Stuttgart
12
CloudCycle
4. Model your topology
© University of Stuttgart
13
CloudCycle
4. Model your topology
© University of Stuttgart
14
CloudCycle
5. Supply parameters to the node templates
© University of Stuttgart
15
6. Model & Import your plan package
Since OpenTOSCA is an imperative container, you
need 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 your
orchestration 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 package
into Winery
CloudCycle

© University of Stuttgart
16
CloudCycle
6. Model & Import your plan package
© University of Stuttgart
17
CloudCycle
6. Model & Import your plan package
© University of Stuttgart
18
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
CloudCycle

© University of Stuttgart
19
8. Provide Self-Service Information

The OpenTOSCA ecosystem provides a Self-Service
Portal which
CloudCycle




Shows all CSARS available in the container with a
description
Allows starting the Build Plan execution by a single click by
passing a predefined (default) plan input message to the
plan
Receives the callback from the plan to show the plan result
to the user
To use this feature, you have to supply the following
as part of the CSAR:


Service description/icon
BuildPlan reference and default input message
© University of Stuttgart
20
CloudCycle
8. Provide Self-Service Information
© University of Stuttgart
21
9. Export finished CSAR file


CloudCycle

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 by
hand and re-packaged
© University of Stuttgart
22
CloudCycle
9. Export finished CSAR file
© University of Stuttgart
23
Further Information
24
A simple example CSAR file
An example CSAR file can be found at:
https://github.com/timwaizenegger/CSAR_Template.git
CloudCycle

It contains a small topology consiting only of an OpenStack
virtual 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 single
command on that machine via SSH
It contains self-service data and can be used from the selfservice portal Vinothek
It contains an ANT script for re-packaging the CSAR file after
manual extraction/modification
© University of Stuttgart
25