MODACloudML IDE - MODAClouds

Grant Agreement

N° FP7-318484

Title:

MODACloudML IDE – Final Version

Authors:

Antonin Abhervé (SOFTEAM), Marcos Almeida (SOFTEAM), Nicolas Ferry (SINTEF), Stepan Seycek (BOC) , Elisabetta Di Nitto (Polimi)

Editor:

Antonin Abhervé (SOFTEAM)

Reviewers:

Danilo Ardagna (Polimi), Daniel Pop (IEAT)

Identifier:

Deliverable D4.3.3

Nature:

Prototype

Version:

1.0

Date:

31/03/2015

Status:

Final

Diss. level:

Public

Executive Summary This document presents the final version of the MODACloudML IDE, which constitutes the kernel of the design time tools of the MODAClouds project. The present document focuses in describing the advances on the IDE from the initial version M24 (documented in D4.3.2 - MODACloudML IDE Proof of concept) to its final version (due at M30). Besides, it presents the functionalities of the IDE at M30, and how they should be used. It also documents the architectural choices and the full requirements to be implemented by the delivered version.

Copyright © 2015 by the MODAClouds consortium – All rights reserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n° 318484 (MODAClouds).

MODAClouds MOdel-Driven Approach for design and execution of applications on multiple Clouds Deliverable # D4.3.3

Members of the MODAClouds consortium: Politecnico di Milano

Italy

StiftelsenSintef

Norway

Institutul E-Austria Timisoara

Romania

Imperial College of Science, Technology and Medicine

United Kingdom

SOFTEAM

France

Siemens srl

Romania

BOC Information Systems GMBH

Austria

Flexiant Limited

United Kingdom

ATOS Spain S.A.

Spain

CA Technologies Development Spain S.A.

Spain

Published MODAClouds documents These documents are all available from the project website located at http://www.modaclouds.eu/

Final Version 1.0, Dated 30/03/2015

2


Contents' 1.! INTRODUCTION+......................................................................................................................................+5! 1.1! 1.2! 1.3! 2!

CONTEXT!.................................................................................................................................................................!5! OBJECTIVES!............................................................................................................................................................!5! STRUCTURE!OF!THE!DOCUMENT!.........................................................................................................................!6!

ACHIEVEMENTS+......................................................................................................................................+7! 2.1! OVERVIEW!OF!THE!STATE!OF!THE!IDE!AT!M24!.............................................................................................!7! 2.1.1! The'Functional'modelling'tool'..............................................................................................................'7! 2.1.2! The'Deployment'and'Provisioning'Component'.............................................................................'8! 2.2! ACHIEVEMENTS!AT!M30!.....................................................................................................................................!9! 2.2.1! The'Functional'modelling'tool'..............................................................................................................'9! 2.2.2! Deployment'and'Provisioning'component'.....................................................................................'10! 2.3! TOOL!INTEGRATION!STRATEGY!.......................................................................................................................!12! 2.4! RELEASE!OF!THE!IDE!........................................................................................................................................!15! 2.4.1! The'IDE'in'Modelio'Community'Website'........................................................................................'15! 2.4.2! Documentation,'Tutorials'and'Examples'.......................................................................................'15! 2.4.3! List'of'final'available'assets'.................................................................................................................'17!

3!

CONCLUSION+.........................................................................................................................................+19!

APPENDIX+A! 1!

IDE+REQUIREMENTS+&+ARCHITECTURE+.................................................................+20!

IDE+FINAL+REQUIREMENTS+..............................................................................................................+20! 1.1! THE!MODACLOUDML!IDE!.............................................................................................................................!20! 1.1.1! Functional'Modelling'Environment'..................................................................................................'20! 1.1.2! CPIM'library'................................................................................................................................................'21! 1.1.3! Deployment'and'Provisioning'Component'....................................................................................'22!

2!

FUNCTIONAL+MODELLING+TOOL+ARCHITECTURE+...................................................................+23!

3!

CPIM+LIBRARY+INTERNAL+ARCHITECTURE+................................................................................+26!

4!

DEPLOYMENT+AND+PROVISIONING+COMPONENT+ARCHITECTURE+...................................+28!

APPENDIX+B! 1!

IDE+OVERVIEW+.....................................................................................................................................+30! 1.1! 1.2! 1.3!

2!

INTRODUCTION!...................................................................................................................................................!30! THE!MODACLOUDS!DESIGNBTIME!APPROACH!............................................................................................!30! THE!MODACLOUDML!IDE!.............................................................................................................................!31!

FUNCTIONAL+MODELLING+TOOL+USER+GUIDE+..........................................................................+34! 2.1! 2.2! 2.3! 2.4! 2.5! 2.6!

3!

USER+GUIDE+.....................................................................................................................+30!

PREREQUISITES!..................................................................................................................................................!34! INSTALLATION!INSTRUCTIONS!........................................................................................................................!34! INITIAL!CONFIGURATION!..................................................................................................................................!34! INTERACTING!WITH!THE!IDE!..........................................................................................................................!40! CCIM!MODELLING!.............................................................................................................................................!42! CPIM!&!CPSM!MODELLING!............................................................................................................................!43!

CPIM+LIBRARY+USER+GUIDE+.............................................................................................................+46! 3.1!

INSTALLATION!INSTRUCTIONS!.........................................................................................................................!46!


3


3.2! 3.3! 3.4! 3.5! 4!

USAGE!OF!THE!CPIM!LIBRARY!........................................................................................................................!46! CONFIGURATION.XML!........................................................................................................................................!46! QUEUE.XML!..........................................................................................................................................................!47! MIGRATION.XML!.................................................................................................................................................!48!

CLOUDML+DEPLOYMENT+AND+PROVISIONING+COMPONENT++USER+GUIDE+.....................+50! 4.1! PREREQUISITES!..................................................................................................................................................!50! 4.2! INSTALLATION!INSTRUCTIONS!........................................................................................................................!51! 4.3! USAGE!GUIDE!......................................................................................................................................................!52! 4.3.1! Deploying'from'the'MODAClouds'IDE'..............................................................................................'52! 4.3.2! CloudML'as'a'library'...............................................................................................................................'53! 4.3.3! CloudML'Shell'.............................................................................................................................................'55! 4.3.4! CloudML'as'a'service'...............................................................................................................................'57! 4.4! USING!CLOUDML!TOGETHER!WITH!PUPPET!................................................................................................!60!

APPENDIX+C!

MODACLOUDML+UML+PROFILE+REFERENCE+........................................................+62!

1!

TOP+LEVEL+.............................................................................................................................................+62!

2!

CCIM+.........................................................................................................................................................+63! 2.1! 2.2! 2.3! 2.4! 2.5!

3!

CPIM+.........................................................................................................................................................+67! 3.1! 3.2!

4!

SERVICES!DEFINITION!.......................................................................................................................................!63! ORCHESTRATION!................................................................................................................................................!64! SERVICE!IMPLEMENTATION!.............................................................................................................................!64! USAGE!MODEL!.....................................................................................................................................................!65! BUSINESS!AND!QOS!REQUIREMENTS!..............................................................................................................!65! DEPLOYMENT!MODEL!........................................................................................................................................!67! QOS!CONSTRAINTS!AND!MONITORING!RULES!..............................................................................................!69!

CPSM+........................................................................................................................................................+71! 4.1! 4.2!

DEPLOYMENT!MODEL!........................................................................................................................................!71! QOS!CONSTRAINTS!AND!MONITORING!RULES!..............................................................................................!73!


4


1. Introduction 1.1 Context The MODACloudML IDE is the piece of software that allows users to design cloud applications mostly independently of the cloud provider. The IDE realizes the model driven engineering (MDE) approach leveraged by MODAClouds by means of the MODACloudML modelling language. MODACloudML allows users of the IDE to design an application in three levels of abstraction: at the CCIM (Cloud Computing Independent Model) level, the high level set of services that compose the application is defined, along with its />


46


We quickly analyze the meaning of the various tags: • : allows you to set the cloud platform choice for the deployment of the application. Possible values are: Glassfish Google Azure Amazon • : This tag includes all -ssh -i "C:\your path to\private.key"

! Before starting CloudML, a configuration file is required which specifies paths to: an SSH tool (such as putty), the mercurial binary, the mercurial configuration file (Mercurial.ini). The content of the mercurial property file (called mercurial.properties) is the following: hgBin=C:\\Program Files\\Mercurial\\hg.exe hgConf=C:\\Program Files\\Mercurial\\Mercurial.ini sshBin=C:\\path_to\\plink.exe

This file should be placed in the same directory than the CloudML executable jar. In case CloudML is executed on Linux the following components are required: • SSH installed • Mercurial installed For now, the access key to the mercurial repository should be placed in ~/.ssh/id_rsa.+

7 8

http://www.cloudsoftcorp.com/community/jclouds/ http://puppetlabs.com


50


4.2 Installation Instructions In order to use CloudML within the MODAClouds IDE, no specific installation operations are required. Please refer to Section 2.6. The deployment and provisioning component is available as an open-source project9 whose releases are available at the following address: https://github.com/SINTEF-9012/cloudml/releases The most up-to-date version of CloudML can be generated from the Github repository. CloudML is implemented with Java as programming language and Maven as a build tool. Accordingly, CloudML can be built using the following command: mvn clean install

CloudML can be built and packaged in three different ways depending on the user needs: 1. As a library that can be used to programmatically build deployment model and perform deployment. 2. As a command line tool, which provide a simple and stand-alone user interface. 3. As a service that can be used to remotely perform deployments. In order to use CloudML as a library, users can add in their classpath the jar file called: 'cloudmllibrary.jar' that has been generated in the 'facade\target' folder. In order to deploy applications on AWS EC2, the ec2 driver: 'aws-ec2-1.7.2.jar'should also be added to the classpath. An archive including all these files is automatically generated when compiling CloudML. CloudML can also be used as a service by starting the jar file called: 'cloudmlWebSocket.jar' that has been generated in the 'ui\websocket\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in the same folder. An archive including all these files is automatically generated when compiling CloudML. The command to start the service is the following: java -jar cloudml-WebSocket.jar

Finally, CloudML can be used as a command line tool by starting the jar file called: 'cloudmlshell.jar' that has been generated in the 'ui\shell\target' folder. This jar file should be placed together with the 'lib' folder that has also been generated in the same folder. An archive including all these files is automatically generated when compiling CloudML. The command to start the service is the following: java -jar cloudml-shell.jar –i

The CloudML log file is available in the "C:\Users\" directory on machines running Windows or in the "/home/yourusername" directory on machines running Linux. For now, CloudML has been tested against the following cloud providers and services: • Amazon EC2 • Flexiant FCO 9

https://github.com/SINTEF-9012/cloudml


51


• • • • • • • •

CloudSigma Openstack nova Amazon Beanstalk Amazon RDS Amazon SQS CloudBees Application container CloudBees database Cloud Foundry v2

4.3 Usage Guide The aim of the MODACloudML deployment and provisioning component (aka. CloudML) is to produce an initial deployment model at the CPSM level to be consumed by the runtime platform. The deployment and provisioning component is then responsible for the provisioning and deployment of the cloud-based system based on this in-memory model. It is also responsible for enriching the CPIM with provider specific data (e.g., type of virtual machine provisioned, name of the image loaded) and runtime data (e.g., public address, domain name).

4.3.1 Deploying from the MODAClouds IDE The MODAClouds IDE can be used to export deployment model as well as to enact a deployment. To export a deployment model, right click on the CPIM or CPSM model and choose the “To Deployment and Provisioning Component” menu item in the “Export...” menu (see Error! Reference source not found.).

Figure 31. Exporting part of the model to the deployment and provisioning component. In addition to the MODAClouds IDE, there are three ways to load a deployment model and to enact the described provisioning and deployment: (i) with the CloudML deployment Shell, (ii) programmatically with the Java API, and (iii) remotely with CloudML as a service.


52


4.3.2 CloudML as a library The facade is the main API of CloudML: it provides a single interface to programmatically trigger the key feature provided by CloudML. Among those key features are: • Loading deployment models in different formats (e.g., XMI, JSON, DOT), • Modifying a deployment models in memory, • Saving changes made on deployment models, • Deploying an application on the basis of its deployment model. From a technical point of view, the facade follows the Command Pattern10: each feature can be triggered by sending the related command to the facade. Command can be executed either in a synchronous or asynchronous way. Synchronous commands will block the client execution until completion, whereas asynchronous commands will let the user continue its own activity while the command is running. Below is the Java interface of the Facade: public interface CloudML extends CommandHandler{ public void fireAndForget(CloudMlCommand command); public void fireAndWait(CloudMlCommand command); public void register(EventHandler handler); public void terminate(); public Deployment getDeploymentModel(); }

The Facade can be used in two modes: local and remote. In the local mode, the CloudML library is actually used to perform the deployment. Below is an example of how can be use the façade to load a deployment and enact it: CloudML cml= Factory.getInstance().getCloudML(); CommandFactory fcommand = new CommandFactory(); CloudMlCommand load = fcommand.loadDeployment(this.jSonFile.getAbsolutePath()); CloudMlCommand deploy = fcommand.deploy(); cml.fireAndWait(load); cml.fireAndWait(deploy);

In the remote mode, the library can be used to trigger a deployment by a remote CloudML started as a service. In order to do so, only one line of code below needs to be updated: CloudML cml= Factory.getInstance().getCloudML("ws://ip:port");

All the commands are available in the Java package org.cloudml.facade.commands. Each command is reified as a separate Java class. The envisioned commands are summarized in the table below as well as their status: 10

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: elements of reusable object-oriented software. Pearson Education


53


Command Name

Description

Implemented

Java Class

deploy

deploy the model currently in memory

Yes

Deploy

destroy

terminate the instance whose ID is given

Yes

Destroy

detach

remove an existing communication between two components

Detach

install

install a given component type on the selected platform

Install

instantiate

create a new instance of the selected component type

Instantiate

list component instances

list the component instances available in the current model

Yes

ListComponentInstance

list component

list the component types available in the current model

Yes

ListComponent

load deployment

load a CloudML deployment model

Yes

LoadDeployment

shot

create a visual snapshot of the deployment model

Yes

Shot

start component

Start a given component instance

Yes

StartComponent

stop component

Stop a given component instance

Yes

StopComponent

store credentials

Store the credentials in use on disk

Store credentials

store deployment

Store the current deployment model Yes on disk

StoreDeployment

uninstall

Uninstall a component instance from the platform currently supporting it

Uninstall

upload

Upload a file on one of the VM described in the model

Yes

Upload

view component

Show the details component type

of

a

given

Yes

ViewComponent

view component instance

Show the details component instance

of

a

given

Yes

ViewComponentInstance

snapshot

Create a snapshot of a given VM

Yes

Snapshot

image

Create an image of a given VM

Yes

Image

scale out

Scale a given VM (and replicate its Yes hosted graph)

ScaleOut

burst

Burst the software hosted by a given Yes VM on a given cloud.

Burst

?

The user of this API can also register to events emitted while commands are executed. The table below summarizes the available events. Registered user will be notified when such events occurs.


54


Event Name

Description

Type

Java Class

Message

A single notification that something has happened. This is used to convey, information, warnings or errors

MESSAGE

Message

component list

Contain the list of requested component types

DATA

ComponentList

component data

Contain the details of a selected component type

DATA

ComponentData

component instance list

Contain the list of requested component instances

DATA

ComponentInstanceList

component instance data

Contain the details of a specific component instance

DATA

ComponentInstanceData

4.3.3 CloudML Shell CloudML also comes along with a shell component, which allows users to load, modify, and enact the deployment specified in CloudML models. The CloudML shell can be executed in two modes: the batch mode and the interactive mode. The batch mode lets users run a single command, whereas the interactive mode lets users input CloudML commands in a step-wise fashion. To run the batch mode, the user must specify the CloudML commands to be executed. Any single command, which is supported by the interactive mode, can be passed on the command line, as done above below with the version command, which simply shows the version number of the CloudML Shell. $> java -jar cloudml-shell.jar version CloudML Shell (v0.0.1) $>

The interactive mode can be started by adding the -i flag to the command. In this mode the user is prompted with command to execute. The commonly used commands are provided below. $> java -jar cloudml-shell.jar -i CloudML Shell (v0.0.1) Copyright (c) 2012 - SINTEF ICT [http://sintef.no] This program comes with ABSOLUTELY NO WARRANTY; See LGPL v3 for details. This is free software, and you are welcome to redistribute it under certain conditions; see LGPL v3 for details. CloudML >

4.3.3.1 The CloudML Shell Commands This session provides a brief description of the commands that can be executed while using the interactive mode of the CloudML Shell.


55


It is worth noting that the CloudML shell supports browsing the history of past commands using the up and down arrows. The table below summarizes the key commands in order to manage a shell session. Name

Syntax

Description

exit

exit

Terminate the Shell Session

quit

quit

Alias for exit

help

help ?

Provide information about the available commands

history

history ?

dump

dump [from ?

replay

replay

Replay all the shell commands stored in the given file

messages

messages ?

Show the d last messages received by the shell from the CloudML back-end

version

version

Show the version of the CloudML shell

List the command you previously entered ]?

to

Write the d last commands of the history into the given file

In addition to the above commands, the CloudML shell also provides a set of commands, which enables interaction with the application running in the Cloud. The table below summarizes these commands: Name

Syntax

Description

load deployment

load deployment from

Load in memory the deployment model stored in the given file

deploy

deploy

Effectively deploy the deployment model in memory.

upload

upload on at

Upload the selected file on the given VM, at the given place

snapshot

snapshot

Create a snapshot of the given VM

create image

create image

Create an image of the given VM

scale out

scale out

burst

burst

debug mode

debug mode true

Start or stop the debug mode. Debug mode displays a trace of the action that are going to be executed by the deployment engine.

store

store deployment to

Store the in-memory deployment model in a file.

from

Scale a given VM (and replicate its hosted graph) to

Burst the software hosted by a given VM on a given cloud.

Some of these commands may take some time to be completed (e.g., uploading a file on a given VM), and one may want to run them as a background task. This can be achieved by appending a '&' symbol at the end of the command.


56


It is worth noting that the CloudML back-end does not execute commands in parallel, but the Shell and the back-end run in parallel. Appending a '&' thus ensures that the shell is not blocked during the execution of a given command, but does not necessarily executes it in a separate process. As shown above, the replay and dump commands allow users to store or rerun sequences of commands specified in a text file. Commented lines must be prefixed by the # character, as shown in the following simple example: # # A simple CloudML Shell Script, which loads # a complete deployment file, and deploys it. # load deployment from apps/sensapp/production.json deploy # ends here!

4.3.4 CloudML as a service CloudML can also be used as a service exploiting Web sockets as a communication protocol. It is worth noting that, by default: (1) the server listens on port 9000, and (2) there is no deployment model loaded when the server starts. Users can change this port number using the following command. java -jar cloudml-websocket.jar portnumber

A CloudML WebSocket service supports four types of commands, which are formatted as YAML, and use XPath to point to the relevant model elements. • getSnapshot for querying the model, • commit for modifying the model, • listen for registering as a listener and being notified when changes occurs in the model, • extend for executing the high level commands defined in CloudML facade. In the following we first present an overview of the existing commands before we detail their syntax. •

Retrieve the whole deployment model loaded into the service

!getSnapshot path : / •

Retrieve the status (an attribute) of a component instance named sensapp-sl1:

!getSnapshot path : /componentInstances[name='sensapp-sl1']/status •

Change the value of the status attribute of a component instance named sensapp-sl1

!commit modifications: - !set parent : /componentInstances[name='sensapp-sl1'] keyValues: status : 'RUNNING'


57


•

Create a new Provider element and add it into the deployment model's provider list

!commit modifications: - !createAndAdd parent : / property : providers type : Provider keyValues : name : provider1 credentials : "" •

Deploy the deployment model that is currently loaded in the service

!extended { name : Deploy } •

Listen to any change in the deployment model

!listenToAny

The above commands are the simplest but most frequently used. We present in the next section the command syntax, which supports more complex, and therefore powerful, commands.

4.3.4.1 Query The getSnapshot command, which is used to retrieve information about the model, follows the syntax described below. instruction !getSnapshot{ path : XPath codec? : String multimaps? : Map } • • •

path is the element or attribute to query. codec indicates the return format, which is, by default, a raw object. multimaps is used to get multiple attribute values together, each with a name to show on the result. For example, the result of the query below will be of the following form: {status : RUNNING, cpu : 80, timestamp : 1234343}.

!getSnapshot path : "/componentInstances[name='sensapp-sl1']" multimaps : { status : status, cpu : properties/cpu, properties/cpu-timestamp }

timestamp

:

4.3.4.2 Modification A commit command consists of a sequence of modifications, which are executed together in a transaction-like fashion. This command follows the syntax described below. instruction !commit{ modifications* : Modification


58


} The set

command, which is used to update attribute values, follows the syntax described

below. modification !set{ parent : XPath keyValues : Map }

Each attribute and its value is specified as a key:value tuple, e.g., !set { parent : "/componentInstances[name='sensapp-sl1']", keyValues : { status : RUNNING, properties/cpu : 80 } }

command, which is used to create a new element to be added in the model, follows the syntax described below. The create

modification !create{ type : Type initializer : List keyValues : Map }

• • •

describes the name of the class to be instantiated in order to create the element. initializer is used to specify a list of type-name tuples that will be used to fill the parameters in the class constructor. keyValues is a key-value map and is used to set the attribute values after creation. type

The add command, which is used to add a new value (newValue) or an existing model element (crossRef) in the model as a child of parent.property, follows the syntax described below. modification !add{ parent : XPath property : Property crossRef : XPath //This is used to add existing objects as a crossreference newValue : Object //simple value index : Object //optional for list, but mandatory for maps }

Because the create and add commands are usually used together, the createAndAdd command combines them and follows the syntax described below. modification !createAndAdd{ parent : XPath property : Property type : Type initializer : List keyValues : Map index : Object }

For instance, the following command adds an instance of VM to the model. !createAndAdd parent : /


59


property : vmInstances type : VMInstance initializer : - {type: String, value: vm1} - {type: VM, value: !xpath /VM/vm1}

Finally, the remove command, which is used to remove a value or an object from the deployment model, follows the syntax described below. modification !remove{ parent : XPath property : Property index : Object value : Object crossRef : XPath }

//-- choose one from index, value, or crossRef //-- But for map, we always need an index

4.3.4.3 High level commands Currently,

the

extend command supports the following Facade commands: LoadDeployment, Deploy, Scale, Start and Stop and follows the syntax described below. instruction !extended{ name : String params* : String } • •

name specifies the name of the command to be executed

params is used to specify the parameters needed to execute the command.

The available commands are detailed below: To start a deployment: !extended { name: Deploy } To start a specific VM: !extended { name: StartComponent, params: [vm1] } To stop a specific VM: !extended { name: StopComponent, params: [vm1] } To burst a VM on a specific cloud provider: !extended { name: Burst, params: [vm1, provider1] } To Scale out a specific VM: !extended { name: ScaleOut, params: [vm1] }

4.4 Using CloudML together with Puppet In order to support Puppet as a configuration management engine that could be used by the CloudML deployment engine to install and configure part of an application on a specific VM, we have defined the concept of PuppetResource, which extends Resource. When this type of Resource is found in a deployment model, CloudML automatically uses the Puppet tool.


60


A PuppetResource contains the following concepts. The properties masterEndpoint, repositoryEndpoint depict the endpoint of the Puppet master node responsible for configuring a Puppet client and of the repository containing the Puppet manifests (describing the configuration), respectively. The properties repositoryKey and username depict the credentials to be used to access to the manifest repository. The puppet manifest describing the software to be installed on a machine can push to the puppet master in several ways. The optional property configurationFile+(see Listing 1)+depicts the name of the manifest to be used by the Puppet master in order to perform the configuration. In addition, CloudML can generate for each VM a manifest that will be pushed to the manifest repository. This manifest is obtained by aggregating all the optional manifestEntry+ (see Listing 2) properties from each component hosted on a VM. Finally, the configurehostname command describes how to modify the hostname of a VM and enables its identification by the Puppet master. ! "puppetResources" : [{ "eClass" : "net.cloudml.core:PuppetResource", "name" : "puppet-client-03", "masterEndpoint" : "109.231.121.6", "repositoryEndpoint" : "ssh://[email protected]//etc/puppet/manifests//cloudml-nodes", "username" : "cloudml", "configurationFile" : "C:\\path_to\\puppet-client-03.pp", "configureHostnameCommand" : "wget http://xxx/configure_hostname.sh; bash configure_hostname.sh" }

Listing 1. A puppet resource exploiting the configurationFile property ! "puppetResources" : [{ "eClass" : "net.cloudml.core:PuppetResource", "name" : "puppet-client-01", "masterEndpoint" : "109.231.121.6", "repositoryEndpoint" : "ssh://[email protected]//etc/puppet/manifests//cloudml-nodes", "username" : "cloudml", "manifestEntry" : "modaclouds::jdk { 'jdk7' : }", "configureHostnameCommand" : "wget http://xxx/configure_hostname.sh; bash configure_hostname.sh" }

Listing 2. A puppet resource exploiting the manifestEntry property! The deployment process is thus as follows: 1. Repository management: a. If the resource comes with a manifest, the repository is cloned and the new file automatically pushed. b. For each VM, a manifest is generated by aggregating the manifestEntry properties of all hosted components. Within the manifest, the name of the node is equal to the name of the VM instance. 2. The hostname of the VM is configured (for now on the basis of the PuppetResource name) 3. Certificate management: if a certificate already exists for this hostname on the master it is removed. 4. Finally, the puppet agent is started. 5.


61


Appendix C reference

MODACloudML

UML

Profile

Each part of the UML profile is presented as a table containing its stereotypes and the base metaclass and tagged values associated to them. The stereotypes and tagged values are named after their metamodel counterparts. For more details on the final MODACloudML metamodel, refer to 4.2.2 and other tools metamodel documentation. The sections in this appendix are illustrated by models coming from the Constellation case study.

1 Top level At its top level a MODAClouds model is represented as a UML package containing other packages that represent its CCIM, CPIM and CPSM submodels.

Stereotype name

Base metaclass Tagged-values

MODACloudMLModel Package CIM

Package

CPIM

Package

CPSM

Package

Legacy

Package

slaCoreUrl(string),slaCoreUser(string), slaCorePassword(string), applicationProvider(string), customer(string), service(string), duration(string)

Figure 32. Illustrative view of the top level of a MODACloudML model.


62


2 CCIM The CCIM model contains a set of service high-level and self-contained descriptions, and besides, a model of how these services are orchestrated, and how users use the system.

2.1 Services definition A service is described by its business and QoS requirements, provided and required interfaces and a model of the exchanged data types.

Stereotype name

Base metaclass

Service

Component

ServiceDescription

Package

ProvidedInterfaces

Package

ExchangeData

Package

RequiredInterfaces

Package

Tagged-values

description(string)

ServiceImplementation Package

Figure 33. Illustrative view of the Services definition on a MODACloudML model.


63


2.2 Orchestration The orchestration model is composed by static and dynamic models. The former describe how services are instantiated and then connected at runtime. The later describe how the services interact, by means of special activity diagrams.

Stereotype name


Orchestration

Package

StaticView

Package

BusinessProcess

Package

ServiceInstance

Instance

DynamicOrchestrationPackage Package DynamicOrchestration

Activity

Figure 34. Illustrative view of the a CCIM model.

2.3 Service implementation The service implementation package contains auxiliary models of the service. It may contain data models, reversed engineered source code and so on. Modellers are free to use and structure service implementation packages as needed.


64


Stereotype name


ServiceImplementation Package

2.4 Usage model Usage models describe how users interact with the application by means of specific activity diagrams extended with specific information such as inter arrival time, population and probabilities. Stereotype name

Base metaclass

UsageModel

Package

Workload

Activity

Tagged-values

workloadElements(string)

Activity OpenWorkload

interArrivalTime(double) Activity

ClosedWorkload

population(string), thinkTime(string) StructuredActivityNode

Branch Clause BranchedBehavior

probability(double) StructuredActivityNode

Loop

specification(int)

OperationParametricResourceDemand Operation

specification(string)

Figure 35. Illustrative view of the a CCIM Usage model.

2.5 Business and QoS requirements Requirements describe constraints to be met by services at CCIM level. Two kinds of constraints are supported, business constraints are textual based constraints while QoS constraints follow the


65


metamodel for constraints defined by WP5. QoB constraints used by SLA mediator are also defined here, by means of QoS constraints metamodel.

Stereotype name

Base metaclass

BusinessRequirementsPackage

Package

QoSRequirementsPackage

Package

BusinessRequirementContainer

Package

BusinessRequirement

Class

Tagged-values

Figure 36. Illustrative view of the CCIM level business requirements and QoS requirements specification.


66


3 CPIM The CPIM model describes the deployment of the application in a provider independent way. It contains a set of deployment alternatives, QoS constraints and Monitoring rules.

3.1 Deployment model These models allow users to define CloudML models at both type and instance levels. These models are linked to CCIM models by means of traceability links supported my Modelio.

Stereotype name


CPIMDeploymentMetamodel Package CPIMDeploymentModel

Package minRAM(int), maxRAM(int), minCPU(int), maxCPU(int), minStorage(int), OS(string), location(string), sshKey(string), securityGroup(string), groupName(string), privateKey(string)

NodeType

Class

Node

Instance

ExternalServiceType

Component

ApplicationType

Component

ExternalService

Instance

Application

Instance

PortType

Port

Server

Port

Client

Port

isOptional(boolean)

Connector

serverDownloadCommand(string), serverInstallCommand(string), serverConfigureCommand(string), serverStartCommand(string), serverStopCommand(string),

BindingType


isRemote(boolean), portNumber(int)

67


clientDownloadCommand(string), clientInstallCommand(string), clientConfigureCommand(string), clientStartCommand(string), clientStopCommand(string), requireCredentials(string), executeLocally(string), bindingType.properties(string)[*]

Binding

Resource

Link

ModelElement

downloadCommand(string), installCommand(string), configureCommand(string), startCommand(string), stopCommand(string), uploadCommand(string)[*], resourceExecuteLocally(string), resourceRequiredCredentials(string)

Port RequiredExecutionPlatform Port ProvideExecutionPlatform Offers

ProvidedInterface offersName(string), offersValue(string)

Demands

RequiredInterface demandsName(string), demandsValue(string)

PaaSBindingType

Connector

PaaSBindingType.properties(string)[*]

Connector Executes Connector ExecutesInstances Dependency ResourcesLink


68


Figure 37. Illustrative view of the CPIM level deployment model.

3.2 QoS constraints and Monitoring rules Along with monitoring rules (already described at CCIM level), users can describe Monitoring rules at CPIM levels. The rules are usually automatically generated from CCIM and CPIM QoS constraints and then extended with the actions that should be performed in case constraints are not respected at runtime.

Stereotype name


CPIMQoSModel

Package

CPIMMonitoringRules

Package

QoSContainer

Package

MonitoringContainer

Package

MonitoringRule


Class

useParentTargets(boolean), metricTransformationUseParentFields (boolean), metricTransformationGroupingCategory( enum{ PROVIDER; REGION; ZONE; OPERATION; SOFTWARE; PLATFORM; RESOURCE; NONE}), metricTransformationTransformation( enum{ AVERAGE;

69


PERCENTILE; WHITEBOX_PREDICTION; BLACKBOX_PREDICTION; MAX; MIN}), metricTransformationParameters(string), useParentActions(boolean), metricName( enum{ CPU_UTILIZATION; RESPONSE_TIME; THROUGHPUT; AVAILABILITY}), timeStep(int), timeWindow(int), startEnabled(boolean), samplingTime(int), samplingProbability(string), actionsNotifyViolation(boolean), actionsPlotMetric(boolean), actionsMigrateToHealthyCloud(boolean), condition(string) monitors

Dependency

targets

Dependency

MonitoringConstraint

Class

metric( enum{ResponseTime; Utilization; Availability; Replication; RAM; Cores; ResourceType; ServiceName; Provider; WLDistribution}), aggregationType( enum{avg; 95thPercentile; 99thPercentile; NULL}), rangeMin(double), rangeMax(double), rangeInSet(string), rangeOutSet(string), priority(integer), unit(string)

MonitoringRuleTransformationSpecification Class MonitoringRuleActionSpecification

Class

Penalty

Class

PenaltyLink

Dependency


70


Figure 38. Illustrative view of the CPIM level QoS constraints and monitoring rules model.

4 CPSM At CPSM level models contain, besides deployment information, cloud provider accounts credentials so that MODAClouds deployed can initialize the required resources at providers; and multi cloud workload models, so that users can define how much cloud resources will be deployed on each specific cloud provider.

4.1 Deployment model Stereotype name


CPSMDeploymentModel

Package

CPSMDeploymentAlternative

Package

multicloudWorkload(string), slaAgreementId(string)

SpecificProvider

Instance

credential(string)

Instance

specific.minRam(string), specific.maxRam(string), specific.minCores(string), specific.maxCores(string), specific.minStorage(string), specific.maxStorage(string), specific.os(string), specific.imageId(string), specific.sshKey(string), specific.securityGroup(string),

SpecificNode


71


specific.groupName(string), specific.privateKey(string), specific.publicAddress(string), specific.isRuntime(boolean), specific.location(string), specific.properties(string)[*]

SpecificExternalService

Instance

specific.login(string), specific.password(string), specifices.properties(string)[*]

SpecificApplication

Instance

status(string)

MulticloudWorkloadPackage

Package

MulticloudWorkloadSpecification

Class

ProviderWorkloadSpecification

Dependency

workload(string)

SpecificProvider

Instance

credential(string)

CloudAccountPackage

Package

Instance CloudAccount

provider.name(string), provider.credential(string), provider.endpoint(string), provider.properties(string)[*]

Figure 39. Illustrative view of the CPSM level deployment model.

Figure 40. Illustrative view of the CPSM level cloud account descriptors.


72


4.2 QoS constraints and Monitoring rules Stereotype name


CPSMQoSModel

Package

CPSMMonitoringRules Package


73