Integrating Conﬁguration Management with

Model-driven Cloud Management based on TOSCA

Johannes Wettinger

, Michael Behrendt

, Tobias Binz

, Uwe Breitenb

ucher

, Gerd Breiter

Frank Leymann

, Simon Moser

, Isabell Schwertle

and Thomas Spatzier

Institute of Architecture of Application Systems, University of Stuttgart, Universit

atsstraße 38, Stuttgart, Germany

IBM Germany Research & Development GmbH, Sch

onaicher Straße 220, B

oblingen, Germany

Keywords:

Model-driven Management, Conﬁguration Management, Service Management, Cloud Services, DevOps.

Abstract:

The paradigm of Cloud computing introduces new approaches to manage IT services going beyond concepts

originating in traditional IT service management. The main goal is to automate the whole management of

services to reduce costs and to make management tasks less error-prone. Two different service management

paradigms are used in practice: conﬁguration management and model-driven Cloud management. The latter one

aims to be a holistic management approach for services in the Cloud. However, both management paradigms

are originating in different backgrounds, thus model-driven Cloud management does not cover all aspects of

conﬁguration management that are key for Cloud services. This paper presents approaches for integrating

conﬁguration management with model-driven Cloud management and how they can be realized based on the

OASIS Topology and Orchestration Speciﬁcation for Cloud Applications and Chef, a popular conﬁguration

management tool. These approaches enable the creation of holistic and highly portable service models.

1 INTRODUCTION

Today, many providers in the ﬁeld of Cloud com-

puting (Leymann, 2011; Mell and Grance, 2011) at-

tract people to create highly scalable applications and

services using the providers’ proprietary offerings.

These can be infrastructure offerings such as Amazon

Web Services

or platform offerings such as Google

App Engine.

Many people get attracted by these offer-

ings because low requirements are put on developers

when starting to create services and applications. The

corresponding meta models are simple and the pro-

vided tooling is easy to use. This results in a very ﬂat

learning curve.

However, when services get more complex, their

management becomes hard (G

unther et al., 2010). It

may be even impossible to move the service to another

Cloud provider because of missing standards that en-

sure portability. The results are vendor lock-in and

bad manageability. Thus, the following main contribu-

tions of this paper are focused on improving the man-

ageability of services in the Cloud without abandon

http://aws.amazon.com

http://developers.google.com/appengine

portability: (1) the direct integration of lower-level

conﬁguration deﬁnitions such as scripts with higher-

level service models. (2) The transparent integration

of conﬁguration deﬁnitions with higher-level service

models, so the type of the conﬁguration deﬁnitions

is completely transparent to the underlying runtime

environment that is responsible for the actual service

deployment and management. (3) Combining the di-

rect and the transparent integration approach to bring

together the strength of both of them and to reduce

their individual shortcomings. To maintain portability,

the actual concepts described in this paper do not stick

to speciﬁc Cloud offerings.

The remainder of this paper is structured as follows:

Section 2 further reﬁnes the actual problem that is the

motivation for this paper. The Topology and Orches-

tration Speciﬁcation for Cloud Applications (OASIS,

2012), hereafter referred to as TOSCA, is presented

as a representative to realize model-driven Cloud man-

agement in Section 3; in addition, Chef is introduced

as an example for conﬁguration management tooling.

We describe the main contributions of this paper in

Section 4, namely the integration concepts. Section 5

shortly describes the implementation that was created

to evaluate the integration concepts and to show their

437

Wettinger J., Behrendt M., Binz T., Breitenbücher U., Breiter G., Leymann F., Moser S., Schwertle I. and Spatzier T..

Integrating Conﬁguration Management with Model-driven Cloud Management based on TOSCA.

DOI: 10.5220/0004376204370446

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 437-446

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

realization. Related work is presented in Section 6.

Section 7 concludes this paper and describes limita-

tions and future work.

2 PROBLEM STATEMENT

As of today, the so called DevOps methodolo-

gies (Humble and Farley, 2010; Humble and Molesky,

2011; Shamow, 2011) represent the leading paradigm

for efﬁciently managing services and applications in a

highly automated manner. The original goal of these

methodologies is to bring together developers and the

operations personnel. This goal is mainly achieved by

automating all the deployment and management tasks.

The actual automation is realized by conﬁguration

management tooling (G

unther et al., 2010; Nelson-

Smith, 2011; Delaet et al., 2010) such as Chef

Puppet.

As a result, the corresponding management

processes are much more reliable and cost less in con-

trast to performing these processes manually. Con-

sequently, it is much easier to deploy and re-deploy

services into different environments such as develop-

ment, test, and production. The philosophy behind

the DevOps movement is to bring agile methodologies

into the world of IT infrastructure and service manage-

ment (Humble and Farley, 2010). This is achieved by

implementing the concept of “Infrastructure as Code”

using conﬁguration management tooling. The concept

is based on the assumption that almost any action on

the infrastructure management level can be automated

programmatically (Smith, 2011). Consequently, prod-

ucts such as Chef or Puppet that implement this con-

cept provide a scripting language or a domain-speciﬁc

language to create and maintain platform-independent

conﬁguration deﬁnitions for deploying and managing

an IT service (G

unther et al., 2010). Of course, con-

ﬁguration management is not limited to implementing

DevOps scenarios. The concept of Infrastructure as

Code targets automation and cost reduction of service

management in general. These are essential parts of

the Cloud computing paradigm (Leymann, 2009; Va-

quero et al., 2008).

However, this approach is not appropriate for man-

aging complex services. Managing a large and sophis-

ticated service topology consisting of different ma-

chines using plain conﬁguration management tooling

can get cumbersome and time-consuming. Even the in-

frastructure for providing a usual Web application can

become complex very quickly: there are several tech-

nologies required to realize load balancing, caching,

http://www.opscode.com/chef

http://www.puppetlabs.com

and a full-text index. To specify such an infrastructure

a lot of “infrastructure code” is being created. As a re-

sult, it is hard to keep the code structure clean because

there is no holistic service model deﬁned including

the service topology that prescribes the structure of a

service that can be instantiated. Every single change

of the “infrastructure code” becomes a risk because it

is hard to estimate the consequences of that particular

change (Nelson-Smith, 2011).

Thus, the paradigm of model-driven Cloud man-

agement provides a more holistic approach for man-

aging a service, but it does not completely replace the

DevOps approach. The model-driven approach does

not target many aspects of DevOps methodologies be-

cause both paradigms are originating in different back-

grounds. As an example, model-driven Cloud man-

agement does not directly specify how to perform the

lower-level actions on a virtual machine to install and

conﬁgure a particular software component. This is why

the main contributions of this paper described in Sec-

tion 4 are focused on bringing together the strengths of

both worlds by integrating conﬁguration management

with model-driven Cloud management to minimize the

shortcomings of the individual approaches.

3 FUNDAMENTALS

The following Section 3.1 outlines the fundamentals of

TOSCA because the concepts presented in this paper

are mainly described using the emerging standard to

realize model-driven Cloud management. Several ex-

amples that are given in this paper are based on Chef,

a popular conﬁguration management product. This is

why we shortly introduce Chef’s basic concepts and

terminology in Section 3.2.

3.1 Topology and Orchestration

Speciﬁcation for Cloud Applications

From a perspective of plain conﬁguration management,

a node is always a physical or virtual machine. How-

ever, the actual topology of an infrastructure to run a

particular service is more than a set of virtual machines

connected to one another. Software components are

running on each machine. These components can be

connected to components running on other machines,

such as an application that connects to a database. Fig-

ure 1 and Figure 2 outline two sample service topolo-

gies for a Web application. They illustrate a much

broader understanding of nodes and relationships. This

understanding leads to a higher-level model-driven

approach for deﬁning the service topology. Such a

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

438

model is not limited to expressing relationships be-

tween different software components hosted on virtual

machines as shown in Figure 1. Nodes can also be

services offered by a Cloud provider as outlined in Fig-

ure 2. Furthermore, additional aspects of the service

topology such as networking can be modeled.

Virtual Machine

Application

Server

connects to

Virtual Machine Virtual Machine

Web

Application

Database

Cache

Server

hosted on

hosted on hosted on hosted on

connects to

Figure 1: Service topology based on virtual machines.

These kinds of service topologies can be modeled

using TOSCA. The result is a self-contained, portable,

and executable service model that can be used to de-

ploy and manage service instances in the Cloud (Binz

et al., 2012). Before TOSCA was introduced, research

focused on migrating services from one Cloud envi-

ronment to another without taking the portability of

management aspects into account (Leymann et al.,

2011; Binz et al., 2011).

Cluster of

Virtual Machines

Application

Container

connects to

Cloud Service

Provider

Web

Application

hosted on

provided by provided by provided by

connects to

Database

Service

Cache

Service

Figure 2: Service topology based on existing services.

The meta model of TOSCA is technically speciﬁed

by an XML schema deﬁnition. It prescribes the struc-

ture of a service template. The key parts to describe

a service topology inside such a service template are:

(1) node types that represent components to be used

inside the topology template. A single node type such

as “database server” can be instantiated once or several

times as a node template inside the topology template.

(2) Relationship types such as “hosted on” can be in-

stantiated as relationship templates inside the topology

template to express any kind of relation between two

particular node templates. (3) The topology template

deﬁnes the actual topological structure of an IT service

such as shown in Figure 1 and Figure 2; it consists of

Terminate

Password

Database Server

Type

Username

Create

Life-

cycle

Shell

Script

Properties Node Type Interfaces Operations Impl.

Artifacts

Figure 3: Example for a TOSCA node type.

node templates and relationship templates.

Figure 3 presents an example for a node type that

deﬁnes a database server component. A node type can

own arbitrary property deﬁnitions such as “username”

and “password” in case of a database server. These

properties are explicitly deﬁned and attached to a par-

ticular node type. Node templates can include concrete

values for these properties. Furthermore, a node type

can own interfaces. A particular interface provides

operations, which deﬁne the possibilities of interac-

tion of a node of the given node type. We assume

that in future versions of TOSCA an arbitrary node

type owns a “lifecycle” interface providing at least

two operations: “create” and “terminate” the node of

a particular node type. As yet, the node type deﬁnition

is abstract and does not say anything about how an

operation is implemented. Thus, one or more concrete

implementation artifacts can be linked to an opera-

tion. Such an implementation artifact is created by

deﬁning an artifact template inside the service tem-

plate. Then, the artifact template can be attached to

at least one operation as an implementation artifact.

For instance, an implementation for the “create” oper-

ation can be a Unix shell script to install the database

server. In addition, another script can be attached to

the same operation that performs the equivalent ac-

tions on Windows-based systems. Attaching several

implementation artifacts to a particular operation im-

proves the portability of the service template because

the operation can be performed on different platforms.

The deﬁnition of relationship types is similar to the

deﬁnition of node types (OASIS, 2012).

TOSCA is not only focused on specifying the ser-

vice topology. Management plans can be deﬁned to

support the whole lifecycle of an application, includ-

ing deployment, maintenance, and termination (Bre-

itenb

ucher et al., 2013). These plans can be deﬁned

using languages such as the Business Process Model

and Notation (OMG, 2011) or the Web Services Busi-

ness Process Execution Language (OASIS, 2007).

All the ﬁles that are referenced inside the service

template such as scripts, binaries, and plans get packed

together with the service template into a Cloud ser-

vice archive (CSAR). The CSAR is completely self-

contained, that is, it contains everything to deploy and

manage the Cloud service that is speciﬁed by the in-

cluded service template. The software that is able to

process CSARs is referred to as a TOSCA runtime

environment.

In terms of Cloud management, there are prod-

ucts and approaches available beside TOSCA such

as VMware’s virtualization and Cloud management,

http://www.vmware.com/solutions

IntegratingConfigurationManagementwithModel-drivenCloudManagementbasedonTOSCA

439

OpenNebula (Miloji

c et al., 2011), OpenStack,

and

others (Han et al., 2009). But these are primarily fo-

cused on the lower-level infrastructure. Their goal is

to simplify the management of virtualized resources

such as virtual machines or storage resources. This

paper is referring to TOSCA because of its holistic and

portable approach to implement model-driven Cloud

management. The emerging standard is supported by

a number of prominent companies in the industry such

as IBM, SAP, and Hewlett-Packard as well as research

institutions.

3.2 Chef

Chef is a popular conﬁguration management product.

Its open source variant is publicly available and can

be used for free. Conﬁguration deﬁnitions in Chef are

called recipes. These are basically scripts written in a

domain-speciﬁc language to express the target state of

a system (G

unther et al., 2010). One or more recipes

are bundled in a cookbook. In addition to cookbooks,

roles can be deﬁned. A particular node can have zero

or more roles. Recipes can be associated with one or

more roles. This mechanism allows to link recipes

to nodes without assigning them directly. The Chef

server stores all the cookbooks and role deﬁnitions. In

addition, the server component manages a “run list”

for each node that is registered. The Chef client runs

on each of these nodes to connect to the Chef server.

A particular run list assigns recipes and roles to a node.

To execute the recipes, there is no Chef server required:

in addition to the Chef client/server mode, there is a

Chef solo mode available. Using this mode, recipes

can be directly executed using the Chef client without

a Chef server (Nelson-Smith, 2011).

Puppet’s architecture is similar to the architecture

of Chef, so the concepts and examples we describe

can be adapted to Puppet. The Puppet master is the

equivalent of the Chef server; the Puppet agent runs

on each node and is thus the equivalent of the Chef

client. Puppet’s manifests, written using a domain-

speciﬁc language and bundled in catalogs, are similar

to Chef’s recipes bundled in cookbooks (Loope, 2011;

Nelson-Smith, 2011). Further, there may be even more

conﬁguration management tools owning a similar ar-

chitecture such as CFEngine.

These can be used to

realize the concepts presented in this paper, too.

4 INTEGRATION CONCEPTS

The main contributions of this paper are outlined in

http://www.openstack.org

http://www.cfengine.com

Virtual Machine Virtual Machine

Declarative scripts

to install and con-

figure the Web

application

Declarative scripts

to install and con-

figure the Web

application

Install and con-

figure Apache,

PHP, Sugar app.,

database conn.

Declarative scripts

to install and con-

figure the Web

application

Declarative scripts

to install and con-

figure the Web

application

Install and con-

figure MySQL,

Sugar database

Figure 4: Deployment using conﬁguration management.

this section: the goal is to bring together the strengths

of conﬁguration management and model-driven Cloud

management in order to minimize their individual

shortcomings. TOSCA is used to realize model-driven

Cloud management by specifying the service template

on a higher level. Such a speciﬁcation includes the

topology template, the node types, and the relation-

ship types. In addition, lower-level implementation

artifacts need to be attached to node type operations

and relationship type operations in order to realize the

operation’s functionality such as installing and conﬁg-

uring a particular software component. Model-driven

Cloud management does not focus on these lower-level

aspects. The straightforward approach is to implement

shell scripts to install and conﬁgure software compo-

nents. Because shell scripts are intended to be used

to perform simple tasks on a speciﬁc platform, us-

ing a platform-independent scripting language such

as Python or Ruby would be a better choice to create

portable artifacts. Otherwise, many platform-speciﬁc

implementation artifacts would have to be attached to

a single operation. However, another two difﬁculties

still remain: (1) it is hard to maintain the scripts be-

cause these scripting languages are general-purpose

languages and do not directly support the domain of

software installation and conﬁguration. (2) It is hard

to design the scripts in a way so that they can be ported

to additional platforms without much effort.

This is why approaches originating in conﬁgura-

tion management are a great ﬁt to further enhance the

value of model-driven Cloud management. As an ex-

ample, Figure 4 presents how Sugar

can be deployed

as a service in the Cloud using plain conﬁguration

management tooling. Sugar is a Web-based customer

relationship management system; its “community edi-

tion” is publicly available as open source software.

For the actual deployment of Sugar, there are two vir-

tual machines provisioned. On the one machine, the

Apache Web server, the PHP module, and the Sugar ap-

plication get installed and conﬁgured by automatically

running artifacts. The MySQL server and the Sugar

database get installed and conﬁgured on the other ma-

chine. To ﬁnish the deployment, the application gets

connected to the database.

http://www.sugarcrm.com

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

440

Virtual Machine

hosted on

Operating System

Apache Web Server

Sugar Application

Virtual Machine

Operating System

MySQL Server

Sugar Database

connects to

hosted on

PHP Module

hosted on

depends on

“Install” and

“Configure” Artifacts

“Install” and

“Configure” Artifacts

“Install” and

“Configure” Artifacts

“Install” and

“Configure” Artifacts

“Install” and

“Configure” Artifacts

“Connect Database”

Artifact

Figure 5: Service topology for deploying and managing Sugar in the Cloud.

All these actions are performed by processing cor-

responding conﬁguration deﬁnitions. The artifacts

are portable, conﬁgurable, and customizable (G

unther

et al., 2010). Using the higher-level service model

based on TOSCA including the service topology

model, the relation of these conﬁguration deﬁnitions

to one another can be deﬁned. Figure 5 outlines the

topology model for the Sugar Cloud service with ar-

tifacts attached including conﬁguration deﬁnitions to

install and conﬁgure the software components that

are running on top of the virtual machines’ operating

system.

In addition to the advantages of using conﬁguration

deﬁnitions regarding portability and maintainability,

conﬁguration management products offer tools and

mechanisms to ease the management of service topolo-

gies. As an example, additional conﬁguration deﬁni-

tions can be assigned to nodes and roles owned by

at least one node in the topology. Typical examples

for activities realized by additional conﬁguration deﬁ-

nitions are updating an application, doing a database

backup, or customizing the conﬁguration of a deployed

application.

For the popular conﬁguration management tools

such as Chef or Puppet, there are conﬁguration deﬁni-

tions already available to install, conﬁgure, and man-

age many software components such as cookbooks

for the Apache Web server and the MySQL database

server. Consequently, they can be easily reused and

combined by creating a service topology model with

conﬁguration deﬁnitions attached.

The following sections discuss two different ap-

proaches to include conﬁguration deﬁnitions into a

service topology model. These are the direct inte-

gration (Section 4.1) and the transparent integration

(Section 4.2). Furthermore, Section 4.3 outlines how

to combine these two approaches to beneﬁt from the

strengths of both.

4.1 Direct Integration

The direct way of embedding conﬁguration deﬁnitions

into a service template is to deﬁne an artifact type,

which ﬁts the structure of the artifacts including con-

ﬁguration deﬁnitions that are created based on a par-

ticular conﬁguration management tool. For instance, a

Chef artifact type needs to be deﬁned to embed Chef

cookbooks into a topology model. We assume that in

future versions of TOSCA a set of standard types of im-

plementation artifacts such as “script artifact” will be

available. Implementation artifacts of these types can

be processed by an arbitrary TOSCA runtime environ-

ment. However, arbitrary types of implementation arti-

facts can be deﬁned by creating an appropriate XML

schema deﬁnition. A TOSCA runtime environment

that processes a service template including custom

implementation artifacts then has to understand the

corresponding artifact type.

Artifact templates are deﬁned inside a TOSCA ser-

vice template and can then be referenced as an im-

plementation artifact for a particular operation. The

following XML snippet represents an example for a

Chef-speciﬁc artifact template that installs and conﬁg-

ures a MySQL database server:

1 <ArtifactTemplate id="mysql-chef-artifact"

2 type="chef:ChefArtifact">

3 <Properties>

4 <chef:ChefArtifactProperties

5 xmlns:chef="http://.../Chef"

6 xmlns="http://.../Chef">

7 <Cookbooks>

8 <Cookbook name="build-essential"

9 location="files/build-essential.zip"/>

10 <Cookbook name="openssl"

11 location="files/openssl.zip"/>

12 <Cookbook name="mysql"

13 location="files/mysql.zip"/>

14 </Cookbooks>

IntegratingConfigurationManagementwithModel-drivenCloudManagementbasedonTOSCA

441

15 <Roles>

16 <Role name="db-server"

17 location="files/db-server.json"/>

18 </Roles>

19 <Mappings>

20 <PropertyMapping mode="input"

21 propertyPath="/RootPassword"

22 cookbookAttribute="mysql/root_pw"/>

23 </Mappings>

24 <RunList>

25 <Include>

26 <RunListEntry roleName="db-server"/>

27 </Include>

28 </RunList>

29 </chef:ChefArtifactProperties>

30 </Properties>

31 <ArtifactReferences>

32 <ArtifactReference reference="files">

33 <Include pattern="build-essential.zip"/>

34 <Include pattern="openssl.zip"/>

35 <Include pattern="mysql.zip"/>

36 <Include pattern="db-server.json"/>

37 </ArtifactReference>

38 </ArtifactReferences>

39 </ArtifactTemplate>

This example outlines the structure of an artifact

template including the generic parts that are common

for each artifact template as well as the Chef-speciﬁc

parts. The ArtifactTemplate element (line 1) itself be-

longs to the generic parts and owns two attributes: the

id attribute speciﬁes a unique identiﬁer for this par-

ticular artifact template inside the service template.

The type attribute speciﬁes the artifact type. The Ar-

tifactReferences element (lines 31–38) including all

its child elements is a generic mechanism for artifact

templates to point to the ﬁles included in the CSAR

that are necessary to process the artifact. In case of

Chef artifact templates, the cookbooks and role deﬁ-

nitions get referenced in this section. The content of

the Properties element (lines 3–30) is Chef-speciﬁc.

The structure of the ChefArtifactProperties element

(lines 4–29) including all its child elements can be

deﬁned using an XML schema deﬁnition including the

following parts:

Cookbooks. Each cookbook that is required to re-

alize a particular artifact template is referenced using

a Cookbook element (lines 8–13). This includes cook-

books that are directly referenced inside the RunList

section as well as dependencies of these.

Roles. Each role deﬁnition that is required to real-

ize a particular artifact template is referenced using a

Role element (lines 16–17). This includes roles that

are directly referenced inside the RunList section as

well as dependencies of these.

Mappings. Values of node type properties can be

mapped to cookbook attributes using a PropertyMap-

ping element (line 20–22). The propertyPath attribute

contains an XPath expression that points to a particu-

lar property. To refer to the corresponding cookbook

attribute, the cookbookAttribute attribute is used. The

same can be done for relationship type properties. Due

to the fact that a relationship owns a source node and

a target node, their property values can be mapped

using a SourcePropertyMapping or a TargetProper-

tyMapping element. If the particular artifact template

implements a script operation, input and output param-

eters can be mapped using an InputParameterMapping

or an OutputParameterMapping element.

RunList. At its core, a Chef artifact template de-

ﬁnes which recipes and roles have to be part of the

corresponding run list. The RunList element (lines

24–28) can contain two child elements: the Include

element consists of at least one RunListEntry element

that points to recipes and roles. These have to be part

of the run list in the given order. The RunListEntry

child elements of the Exclude element denote recipes

and roles that have to be explicitly excluded from the

run list. A RunListEntry element can either point to

a role as shown before or it can directly refer to a

particular recipe:

1 <RunListEntry cookbookName="mysql"

2 recipeName="install"/>

As an additional remark regarding the deﬁnition

of property mappings, the mode attribute speciﬁes

the mapping direction: “input” means that the prop-

erty value is mapped to the cookbook attribute be-

fore the Chef recipes are executed, “output” maps

the cookbook attribute to the property after the Chef

recipes were executed, and “input-output” combines

both kinds of mapping.

This is how Chef artifact templates can be realized

using the direct integration approach. The TOSCA

runtime environment has to understand the content

of the ChefArtifactProperties element to perform the

corresponding actions. However, it is completely up to

the TOSCA runtime environment how to perform these

actions. Two options are: the Chef server’s REST API

and Chef’s command line interface. Furthermore, the

artifact template does not prescribe whether a Chef

server is required to realize the artifact. Alternatively,

the TOSCA runtime environment can just use a Secure

Shell connection (SSH) to push the cookbooks and

role deﬁnitions to the nodes and then use Chef solo to

execute them.

4.2 Transparent Integration

Conﬁguration deﬁnitions can also be embedded into a

service topology model in a transparent way using the

standard artifact type “script artifact.” Consequently,

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

442

Wrapper

Script

Chef Client

TOSCA Runtime

Environment

Target Node

copy

call

Figure 6: Transparent integration using a wrapper script.

the TOSCA runtime environment does not have to un-

derstand implementation artifacts of custom artifact

types such as Chef-speciﬁc artifacts. Of course, we

assume that an arbitrary TOSCA runtime environment

can process artifacts of type “script artifact” as men-

tioned in Section 4.1. In practice, this approach of inte-

grating conﬁguration management can be realized by

creating “wrapper scripts” that call the conﬁguration

management tool with corresponding parameters to

point to the conﬁguration deﬁnitions. Figure 6 shows

how wrapper scripts are used to perform operations

on a target node using Chef: ﬁrst, the TOSCA run-

time environment copies the corresponding wrapper

script to the target node and then triggers its execution;

additional ﬁles that are required for the execution of

the wrapper script are copied to the target node, too.

Second, the wrapper script calls the Chef client. These

wrapper scripts can be attached to the topology model

using implementation artifacts of type “script artifact”

in TOSCA. However, some constraints such as the

conﬁguration of the agent that processes the conﬁg-

uration deﬁnitions are hard-wired inside the wrapper

scripts. The result is a loss of ﬂexibility to process

conﬁguration deﬁnitions because the TOSCA runtime

environment does not understand what is happening

inside a wrapper script. It cannot control how the

wrapper script performs its work. In addition, it is

hard to make the wrapper scripts portable. The follow-

ing XML snippet presents an example for a wrapper

artifact template of type “script artifact:”

1 <ArtifactTemplate id="mysql-wrapper"

2 type="af:ScriptArtifact">

3 <Properties>

4 <af:ScriptArtifactProperties

5 xmlns:af="http://.../StandardArtifacts"

6 xmlns="http://.../StandardArtifacts">

7 <ScriptLanguage>sh</ScriptLanguage>

8 <PrimaryScript>

9 scripts/mysql-install.sh

10 </PrimaryScript>

11 </af:ScriptArtifactProperties>

12 </Properties>

13 <ArtifactReferences>

14 <ArtifactReference reference="files">

15 <Include pattern="build-essential.zip"/>

16 <Include pattern="openssl.zip"/>

17 <Include pattern="mysql.zip"/>

18 <Include pattern="db-server.json"/>

19 </ArtifactReference>

20 <ArtifactReference reference="scripts">

21 <Include pattern="mysql-install.sh"/>

22 </ArtifactReference>

23 </ArtifactReferences>

24 </ArtifactTemplate>

This artifact template implements the very same

operation as the Chef-speciﬁc artifact template pre-

sented before (Section 4.1). The content of the Scrip-

tArtifactProperties element (lines 4–11) is limited to

some generic meta data regarding the corresponding

script. All the Chef-related information such as the

mappings and the run list entries are hidden inside

the wrapper script “mysql-install.sh.” As a result, the

Chef speciﬁcs of the artifact template are completely

transparent to the TOSCA runtime environment: the

runtime implementation does not have to know any-

thing about Chef. However, all the actions necessary

to realize the artifact are hard coded inside the wrap-

per script: the TOSCA runtime environment does not

have much ﬂexibility in performing the corresponding

actions. Whereas for the direct integration approach

the mapping of properties and parameters is explicitly

deﬁned inside the artifact template, these mappings

are hidden inside the wrapper script for the transparent

integration. The TOSCA technical committee did not

establish a standardized convention yet how scripts

can access properties of nodes and relationships. One

possible convention for TOSCA runtime environments

is to expose all properties as system environment vari-

ables to the script. As an example, the wrapper script

can access the “$RootPassword” variable to get the

value of the node type property “RootPassword.” All

the knowledge how to map these property values to

the conﬁguration management tool is part of the logic

implemented inside the script.

4.3 Combined Integration

The transparent integration approach is not meant to be

used solely because wrapper scripts are not intended

to be created manually. The goal of the combined

integration is to bring together the strengths of both

integration approaches by including two alternative

artifact templates for each operation as outlined in Fig-

ure 7: one that follows the direct integration approach

and another one that follows the transparent integra-

tion approach. However, the artifact templates that are

based on the transparent integration approach includ-

ing wrapper scripts are not created manually. They

are programmatically generated based on the artifact

templates that follow the direct integration approach.

Then, the TOSCA runtime environment can decide

whether to process the standard artifacts or to process

the custom artifacts if the corresponding artifact type is

understandable for the particular TOSCA runtime en-

vironment. The actual decision of the TOSCA runtime

IntegratingConfigurationManagementwithModel-drivenCloudManagementbasedonTOSCA

443

Table 1: Comparison of direct, transparent, and combined integration.

Direct Int. Transparent Int. Combined Int.

TOSCA runtime environment can process conﬁguration deﬁnitions directly + – +

TOSCA runtime environment does not have to understand custom artifact types – + +

High degree of portability – – +

environment which artifact template to process can

be made based on certain compliance rules. Because

wrapper scripts are “black boxes” for the TOSCA run-

time environment and could possibly contain harmful

content, the TOSCA runtime environment may always

prefer artifact templates that follow the direct integra-

tion approach.

Terminate

Password

Database Server

Type

Username

Create

Life-

cycle

Chef

Recipe

Wrapper

Script

Figure 7: Combined integration results in two alternative

implementation artifacts for each operation.

Beside the approach of programmatically gener-

ating individual wrapper scripts as mentioned before,

a generic wrapper script can be built that can be pa-

rameterized and thus used to process arbitrary Chef

recipes. This approach of building generic wrap-

per scripts can be extended by establishing a public

community-driven repository to share generic wrap-

per scripts. These scripts enable an arbitrary TOSCA

runtime environment that only understands implemen-

tation artifacts of a speciﬁc type such as “script artifact”

to process any other type of artifacts if there is a cor-

responding wrapper script available. As a result, the

creator of a CSAR can use his preferred conﬁguration

management tool or scripting language to implement

node type operations and then include parameterized

wrapper scripts to make the CSAR portable. Conse-

quently, this approach enables separation of concerns

because the CSAR creator can stick to his domain and

include wrapper scripts to improve the portability of a

CSAR.

Table 1 summarizes beneﬁts and drawbacks of the

integration approaches described in this section. It un-

derlines that the combined integration approach brings

together the strengths of both the direct and the trans-

parent integration approach leading to a high degree

of portability. This is achieved either by generating

individual wrapper scripts for each operation or by

using generic wrapper scripts. Both the direct and the

transparent integration approach alone do not lead to a

high degree of portability because either the TOSCA

runtime environment has to understand custom artifact

types or some constraints are hard-wired inside the

wrapper scripts.

5 EVALUATION

To evaluate the concepts presented in Section 4 and

to show that they are applicable in practice, we built

two CSARs that realize the Sugar service topology

presented in Figure 5. The ﬁrst CSAR is based on

the direct integration approach including one Chef-

speciﬁc artifact for each operation. The second CSAR

realizes the combined integration approach by addi-

tionally attaching equivalent implementation artifacts

of type “script artifact” to each operation, including

individually generated wrapper scripts. Both CSARs

are completely self-contained including all Chef cook-

books and role deﬁnitions.

We did not include any management plans into the

CSARs. As a result, a TOSCA runtime environment

has to understand the declarative model that is deﬁned

by the topology template. In contrast to an imperative

model, a declarative model does not include a “build

plan” that explicitly speciﬁes the steps required to be

performed to deploy a service instance. To enable

the declarative approach of deploying a CSAR, we

assume that the lifecycle operation “create” is part of

each node type. Implementation artifacts to install

and conﬁgure the corresponding software component

are attached to these “create” operations. The deploy-

ment of a declarative model is implemented by travers-

ing the topology template and calling the “create” op-

erations. All “create” operations of the middleware

stack inside the service topology such as the Apache

Web server and the MySQL database server are imple-

mented using cookbooks that are publicly shared by

the Chef community.

The only cookbook that we im-

plemented manually is the Sugar cookbook. It includes

recipes to install and conﬁgure the application, to set

the Sugar database up, and to connect the application

to the database.

In addition, we enabled the deployment of the

CSARs in three different ways: (1) we implemented a

lightweight TOSCA runtime environment that can pro-

cess Chef-speciﬁc implementation artifacts attached to

the “create” operations. These artifacts get processed

by Chef solo. This is realized by copying the Chef

cookbooks and role deﬁnitions to the target node us-

ing SSH and then calling the Chef client in Chef solo

http://community.opscode.com

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

444

mode with the corresponding parameters. (2) We ex-

tended the current TOSCA runtime environment of

the IBM SmartCloud Orchestrator

to process Chef-

speciﬁc artifacts either using an existing Chef server

or by Chef solo. The Chef solo variant is implemented

similarly to the implementation outlined before us-

ing SSH. In case of the Chef server variant the Chef

server’s REST API is used to upload the cookbooks

and role deﬁnitions and to assign recipes and roles to

the nodes that are registered at the Chef server. Then,

the Chef client running on each node retrieves and

processes the assigned cookbooks and role deﬁnitions.

In addition, we utilized the Chef server to perform

simple management tasks regarding the deployed ser-

vice instance. (3) A student team developed another

lightweight TOSCA runtime environment during the

“Extreme Blue 2012” summer internship at IBM. It

understands implementation artifacts of type “script

artifact” only. However, it is able to process the CSAR

that was created based on the combined integration

approach without any extension or modiﬁcation. It

basically executes the wrapper scripts, which then call

the Chef client with the corresponding parameters.

6 RELATED WORK

Because large and complex service topologies are

hard to manage using plain conﬁguration management,

the DevOps community establishes additional higher-

level tooling such as Marionette Collective (Turnbull

and McCune, 2011; Loope, 2011) and Spiceweasel.

These tools provide more convenience to manage clus-

ters and collections of nodes. Marionette Collective

provides a framework that can be used in conjunction

with both Puppet and Chef. Spiceweasel is a Chef-

based command line tool to ease the management of a

set of nodes, but it is much simpler and more limited

compared to Marionette Collective. The conﬁgura-

tion of a collection of nodes can be described using

a document written in “JavaScript Object Notation”

(JSON). Then, several Chef commands are being gen-

erated based on this document to perform the actual

deployment. However, these tools do not lift conﬁgura-

tion management tooling to the level of model-driven

management because they do not introduce a holistic

meta model for managing complex service topologies

as TOSCA does.

Similar to Spiceweasel, Amazon Web Services’

CloudFormation

is a service offering to manage a

http://ibm.co/CPandO

http://wiki.opscode.com/display/chef/Spiceweasel

http://aws.amazon.com/cloudformation

set of resources in the Amazon Cloud. CloudForma-

tion templates are written in JSON and can be used

to instantiate and conﬁgure a set of resources such as

virtual machines and object stores. In contrast to a

TOSCA service template, a CloudFormation template

does not include a holistic service topology model in-

cluding relationships between nodes. Further, a Cloud-

Formation template can only refer to resources that are

available inside the Amazon Cloud.

Canonical Juju

is a service orchestration frame-

work for sharing and reusing DevOps best practices

in the form of self-contained units. These shareable

and reusable units are called “charms.” A single charm

represents a service model that can be instantiated.

In addition, relations can be established between ser-

vice instances, so Juju’s meta model has similarities to

TOSCA. As a result, Juju enables model-driven Cloud

management. However, there are limitations when it

comes to portability because Juju is strongly focused

on the ecosystem around the Ubuntu Linux distribu-

tion. The scripts included in a charm representing the

implementation artifacts are usually shell scripts or

Python scripts designed to be executed on a Ubuntu

Linux system only.

7 SUMMARY AND OUTLOOK

We presented concepts to integrate conﬁguration man-

agement with model-driven Cloud management. The

goal was to bring together the strengths of both ser-

vice management paradigms. This was achieved based

on TOSCA, an emerging standard to realize model-

driven Cloud management. Different concepts were

described how to include conﬁguration deﬁnitions into

a CSAR: the direct integration of artifacts including

conﬁguration deﬁnitions requires the TOSCA runtime

environment to understand the corresponding artifact

type. However, there are no hard-wired constraints

included in the artifacts, so the TOSCA runtime envi-

ronment has a high degree of ﬂexibility in processing

the artifacts. The transparent integration approach can

be used to enable the processing of conﬁguration def-

initions in a TOSCA runtime environment that does

not understand the corresponding artifact type. Both

integration approaches can be combined to make a

CSAR highly portable. These integration concepts

are following the design principles of TOSCA and

their implementation does not need any extension of

TOSCA itself. The integration of conﬁguration deﬁni-

tions is the foundation for creating portable CSARs.

There are many conﬁguration deﬁnitions publicly

http://juju.ubuntu.com

IntegratingConfigurationManagementwithModel-drivenCloudManagementbasedonTOSCA

445

available that can be reused. These can be included

into a CSAR without modifying them. Conﬁguration

deﬁnitions can also be used to perform simple man-

agement tasks. However, conﬁguration deﬁnitions are

created using a domain-speciﬁc language (G

unther

et al., 2010). Consequently, that speciﬁc language has

to be learned when manually creating such an artifact.

The examples and the evaluation presented in this

paper were strongly related to Chef. However, the

underlying concepts are not Chef-speciﬁc. As a result,

the integration concepts can be adapted to be used and

implemented in conjunction with other conﬁguration

management tooling such as Puppet because they own

a similar architecture as outlined in Section 3.2. This

will be evaluated in future work.

OpenTOSCA

is an open source implementation

that provides a TOSCA runtime environment. Cur-

rently, OpenTOSCA is being extended to process im-

plementation artifacts of type “script artifact.” Then,

the integration concepts described in Section 4 can be

further evaluated based on OpenTOSCA.

Moreover, it will be evaluated how existing con-

ﬁguration deﬁnitions can be reused even more eas-

ily in the world of model-driven Cloud management.

This makes sense because of the existing and growing

ecosystems of conﬁguration management products.

The contributions described in Section 4 are mainly

limited to service deployment. Future research will

focus on utilizing conﬁguration management for man-

agement tasks that are performed after the actual de-

ployment of a service instance. The goal is to orches-

trate conﬁguration deﬁnitions using management plans

as they can be deﬁned in a TOSCA service template.

ACKNOWLEDGEMENTS

The research leading to these results has partially re-

ceived funding from the 4CaaSt project from the Euro-

pean Union’s Seventh Framework Programme (FP7/

2007-2013). Further, this work was partially funded

by the BMWi project CloudCycle (01MD11023).

REFERENCES

Binz, T., Breiter, G., Leymann, F., and Spatzier, T. (2012).

Portable Cloud Services Using TOSCA. Internet Com-

puting, IEEE, 16(3):80–85.

Binz, T., Leymann, F., and Schumm, D. (2011). CMotion:

A Framework for Migration of Applications into and

between Clouds. In 2011 IEEE International Confer-

ence on Service-Oriented Computing and Applications.

IEEE.

http://www.iaas.uni-stuttgart.de/OpenTOSCA

Breitenb

ucher, U., Binz, T., , Kopp, O., and Leymann, F.

(2013). Pattern-Based Runtime Management of Com-

posite Cloud Applications. In Proceedings of the 3rd

International Conference on Cloud Computing and

Services Science (CLOSER).

Delaet, T., Joosen, W., and Vanbrabant, B. (2010). A Survey

of System Conﬁguration Tools. In Proceedings of the

24th Large Installations Systems Administration (LISA)

conference.

unther, S., Haupt, M., and Splieth, M. (2010). Utilizing In-

ternal Domain-Speciﬁc Languages for Deployment and

Maintenance of IT Infrastructures. Technical report,

Very Large Business Applications Lab Magdeburg,

Fakult

at f

ur Informatik, Otto-von-Guericke-Universit

Magdeburg.

Han, H., Kim, S., Jung, H., Yeom, H., Yoon, C., Park, J., and

Lee, Y. (2009). A RESTful Approach to the Manage-

ment of Cloud Infrastructure. In 2009 IEEE Interna-

tional Conference on Cloud Computing (CLOUD’09).

Humble, J. and Farley, D. (2010). Continuous Delivery: Re-

liable Software Releases Through Build, Test, and De-

ployment Automation. Addison-Wesley Professional.

Humble, J. and Molesky, J. (2011). Why Enterprises Must

Adopt Devops to Enable Continuous Delivery. Cutter

IT Journal, 24(8):6.

Leymann, F. (2009). Cloud Computing: The Next Revolu-

tion in IT. In Photogrammetric Week ’09. Wichmann

Verlag.

Leymann, F. (2011). Cloud Computing. it – Information

Technology, 53(4).

Leymann, F., Fehling, C., Mietzner, R., Nowak, A., and

Dustdar, S. (2011). Moving Applications to the Cloud:

An Approach Based on Application Model Enrichment.

International Journal of Cooperative Information Sys-

tems, 20(3):307.

Loope, J. (2011). Managing Infrastructure with Puppet.

O’Reilly Media, Inc.

Mell, P. and Grance, T. (2011). The NIST Deﬁnition of

Cloud Computing. National Institute of Standards and

Technology.

Miloji

c, D., Llorente, I., and Montero, R. (2011). Open-

Nebula: A Cloud Management Tool. Internet Comput-

ing, IEEE, 15(2):11–14.

Nelson-Smith, S. (2011). Test-Driven Infrastructure with

Chef. O’Reilly Media, Inc.

OASIS (2007). Web Services Business Process Execution

Language (BPEL) Version 2.0.

OASIS (2012). Topology and Orchestration Speciﬁcation for

Cloud Applications (TOSCA) Version 1.0, Committee

Speciﬁcation Draft 04.

OMG (2011). Business Process Model and Notation

(BPMN) Version 2.0.

Shamow, E. (2011). Devops at Advance Internet: How We

Got in the Door. IT Journal, page 14.

Smith, D. (2011). Hype Cycle for Cloud Computing, 2011.

Turnbull, J. and McCune, J. (2011). Pro Puppet. Apress.

Vaquero, L., Rodero-Merino, L., Caceres, J., and Lindner, M.

(2008). A Break in the Clouds: Towards a Cloud Def-

inition. ACM SIGCOMM Computer Communication

Review, 39(1):50–55.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

446