Sublimated Conﬁguration of Infrastructure as a Service Deployments

MING: A Model- and View-Based Approach for Cloud Datacenters

Ta’id Holmes

Infrastructure Cloud, Deutsche Telekom Technik GmbH, Darmstadt, Germany

Keywords:

Cloud, Code Generation, Conﬁguration, Datacenter, Deployment, DSL, IaaS, JuJu, MBE, Metamodel,

OpenStack.

Abstract:

For establishing the basic cloud service model, a datacenter (DC) needs to deploy an infrastructure as a service

(IaaS) solution. The planning, setup, implementation, and operation of DCs – involving hard- and software –

comprises multiple activities. At least, software-related aspects such as IaaS deployment can be automated. Yet,

in the forefront of an automated installation extensive conﬁgurations need to take place. These conﬁgurations

often relate to the design and characteristics of the respective DC. Using existing deployment technologies,

however, information from various aspects are scattered and tangled. For avoiding respective drawbacks and

resulting adverse effects, MING (

明

) – a model-based approach – is presented. It decouples conﬁguration

from automated deployment technologies. This way, various further beneﬁts of model-based engineering are

leveraged such as separation of concerns through view-based models, platform independent representation of

information, and the utilization of existing deployment technologies through code generation.

1 INTRODUCTION

The cloud computing paradigm continues to change

the way end-users consume services. At the same time

service providers adapt (cloudify) software services

(cf. (Andrikopoulos et al., 2013)) for proﬁting from

the beneﬁts of cloud computing. Thus, cloud comput-

ing penetrates all levels from DCs to end-users. On

an infrastructure level cloud computing offers (virtual-

ized) hardware resources and network capabilities as

IaaS (cf. (Mell and Grance, 2011)). This impacts the

design and deployment of DCs.

For this reason the planning, implementation, and

operation of DCs has changed. Above all, cloud DCs

distinguish themselves from traditional DCs by having

an IaaS solution deployed. The IaaS solution estab-

lishes the correspondent service model while man-

aging the DC resources. These resources comprise

computational power from central processing units

(CPUs), random-access memory (RAM), storage in

the form of objects stores or block devices from hard

drive disks (HDDs) and solid-state drives (SSDs), and

network interfaces. All of these need to be registered

and managed by the IaaS solution.

OpenStack

is a popular IaaS solution with a big

community and support across industries. For easing

http://openstack.org

the installation and deployment of OpenStack various

automated deployment technologies and tools exist.

Often they are provided from an operating system

(OS) vendor as a kind of value proposition.

For realizing installation of bare machines and the

deployment of the IaaS solution, currently, various

information needs to be aggregated in conﬁgurations

by experts who are familiar with the technologies. Of-

ten the information relates to different aspects and is

scattered and tangled and needs to be kept consistent.

Changes in the design or characteristics of a DC may

impact the conﬁguration fundamentally: e.g., network-

ing, number of availability zones in a DC, or dedication

of a certain node to some aggregate.

Ideally, it would be possible to describe the various

aspects of a cloud DC (i.e., the hardware, the network-

ing) and its deployment (i.e., the services) conceptually

in a domain-speciﬁc language (DSL) so that from such

information as contained in the respective views the

automated DC deployment can take place. While sev-

eral deployment tools exist (that in fact can all be made

use of following the model-based approach) there is

no technology agnostic datamodel for specifying a DC

deployment that is understood by tools.

Therefore, MING (

明

), a model-based approach, is

proposed: It permits the model- and view-based de-

scription of DCs and respective IaaS deployments by

308

Holmes, T.

Sublimated Conﬁguration of Infrastructure as a Service Deployments - MING: A Model- and View-Based Approach for Cloud Datacenters.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 2, pages 308-313

ISBN: 978-989-758-182-3

means of a platform-independent model (PIM). This

way, separation of concerns (SoC) is realized support-

ing different stakeholders. Also, integration with exist-

ing tools is realized using code generation.

The remainder of this paper is structured as fol-

lows: The following section presents some further

background by explaining tasks when deploying a

cloud DC. Prior to presenting the MING approach

in Section 4, Section 3 relates to the state of the art.

Next, Section 5 presents some details of the current

prototype. Section 6 discusses on the beneﬁts, risks,

and limitations and Section 7 concludes the paper.

2 DATACENTER DEPLOYMENT

The planning, setup, implementation, and operation

of a DC comprises multiple activities involving hard-

and software. Prior to focusing on the latter, i.e., the

automated software installation and deployment, this

section ﬁrst looks at the structure of DCs.

2.1 Structure of Datacenters

Figure 1 depicts a simple metamodel for DCs (that is

also part of the MING metamodel, cf. Figure 2). A

DATACENTER comprises one or several AVAILABIL-

ITYZONES. These may be ﬁre compartments that

are separated from each others. Each AVAILABILITY-

ZONE contains RACKS for mounting equipment such

as routers and servers (NODE). A server comprises

network interface controllers (NICs), CPU, RAM, and

storage in form of HDDs and/or SSDs. Each NIC has

a unique media access control (MAC) address. For

networking (cf. Layer 3 of the Open Systems Intercon-

nection (OSI) reference model (Zimmermann, 1980))

a NIC will be conﬁgured at some stage with an Inter-

net Protocol (Cerf and Khan, 1974) (IP) address, e.g.,

using Dynamic Host Conﬁguration Protocol (Droms,

1997) (DHCP). Within a NETWORK (i.e., IP4 and NET-

MASK) a NIC has a particular NETWORKID (e.g, the

last byte of the address).

INSTALLATION nodes are used for bootstrapping

the DC deployment. Generally it is possible to group

servers into different categories: STORAGE nodes con-

tain a large amount of storage capacity while COM-

PUTE nodes have high computational power. NET-

WORK nodes may comprise ﬁber optical NICs for high

bit rates. Finally, MANAGEMENT nodes are dedicated

for hosting IaaS services (see also Section 2.2).

Intelligent Platform Management Interface (IPMI)

may provide an administrative access to the servers

through a dedicated network. Besides, all servers may

name : EString

DataCenter

name : EString

desc : EString

AvailabilityZone

name : EString

desc : EString

Rack

name : EString

nodeType : NodeTypeName = standby

desc : EString

arch : Arch = amd64

ram : EInt

Node

diskType : DiskType = HDD

desc : EString

dev : EString

Disk

mac : EString

dev : EString

NIC

size : EInt

unit : Unit = GB

Size

id : EInt

NetworkID

standby

installation

management

compute

network

storage

NodeTypeName

name : EString

desc : EString

vlanID : EInt

ip4 : EString

netmask : EInt

Network

racks

* nodes

* azs

* nics* disks

1 netID

net

1 diskSize

Figure 1: A Datacenter Metamodel.

be part of multiple physical or virtual (VLANID) net-

works. For example, storage nodes may have a back-

end network for replication in addition to a frontend

network for the data.

2.2 Software Installation

Given a DC with a completed physical setup including

networking and cabling, installation of the bare ma-

chines can take place (see also Section 3.1). That is,

on each node a base OS is installed over the net, e.g.,

using IPMI and Preboot Execution Environment (In-

tel Corporation, 1999) (PXE) together with a DHCP

server. Yet, some information needs to be collected

beforehand and placed at the DHCP server such as the

MAC addresses of the NICs. This information may be

discovered automatically.

Sublimated Conﬁguration of Infrastructure as a Service Deployments - MING: A Model- and View-Based Approach for Cloud Datacenters

309

Next, IaaS services can be installed (see also Sec-

tion 3.2). STORAGE servers may deploy Ceph (Weil

et al., 2006), a distributed object store. COMPUTE

nodes run OpenStack Compute (Nova). OpenStack

Networking (Neutron) is used for NETWORK nodes.

Finally, MANAGEMENT nodes host services such as

OpenStack Identity Service (Keystone), Nova cloud

controller, OpenStack Orchestration (Heat), and Open-

Stack Dashboard (Horizon).

Having brieﬂy introduced the deployment of cloud

DCs, the following section discusses different existing

deployment tools for realizing the installation.

3 STATE OF THE ART

Prior to presenting the MING approach let us ﬁrst have

a look at the state of the art. At the end of this sec-

tion, a current shortcoming of the existing deployment

technologies is summarized for positioning the con-

tribution of this paper. As outlined in the previous

section there are two distinct phases in the deployment

of DCs: bare machine and IaaS installation with some

of the tools focusing on the former and others on the

latter.

3.1 Bare Machine Installation

The following selection of tools and projects focus

on installing a base OS on bare machines (cf. (Chan-

drasekar and Gibson, 2014) for the evaluation of some

frameworks).

Cobbler

is a lightweight build and provisioning

system for the deployment of physical and virtual ma-

chines. Objects and variables are used for conﬁgur-

ing the provisioning. These are then applied in tem-

plates, e.g., for generating preseed ﬁles. This way, i.e.,

through templates, Cobbler also integrates with Kick-

start. Generally, integration with existing tools and

conﬁguration management (CM) systems is encour-

aged. In addition to a command-line interface (CLI)

there is a also a web user interface (UI). Cobbler is

currently used by Compass and Fuel (see Section 3.2).

FAI

, with a particular focus on unattended au-

tomated installations, builds – as Cobbler – on top

of technologies such as DHCP, Trivial File Transfer

Protocol (Sollins, 1992) (TFTP), and PXE. Originally

focusing on Debian-based distributions, FAI has been

adopted for CentOS. It realizes proﬁles in addition to a

class concept that can help to describe complex setups.

http://cobbler.github.io

Fully Automatic Installation (G

artner et al., 1999;

Lange, 2010) (FAI). http://fai-project.org

Ironic

is used for the provisioning of physical

machines within OpenStack. Thus, in contrast to the

other tools of this category, it is not a self-contained

system. Its functionality is used by TripleO and will

also be relied on by Fuel.

MAAS

is used for the provisioning of Ubuntu in

combination with JuJu and Charms (see Section 3.2).

Similar to Cobbler and FAI, a MAAS server acts as a

DHCP server for the provisioning of machines. Con-

ﬁguration such as MAC to IP mapping can be done in

a JuJu YAML Ain’t Markup Language (YAML) ﬁle

(see also Section 5).

3.2 OpenStack Installation

The automated provisioning, conﬁguration, and instal-

lation of services is addressed by CM systems. Thus,

after each node has been installed with an OS, the

installation and conﬁguration of IaaS services can be

realized using CM. For the deployment of OpenStack

there is a variety of existing tools:

Compass

supports different CM systems through

a plugin architecture. By establishing abstraction lay-

ers, it also decouples resource discovery and bare metal

installation. Besides, it facilitates operations support

system (OSS) integration.

Crowbar

is a project that relies on the Chef CM

system for the deployment of applications such as

OpenStack or Hadoop. In contrast to other solutions

of this category it does not presume but also realizes

bare metal installation and comes with a web UI.

Fuel

offers a web UI frontend for the deploy-

ment of OpenStack in addition to a CLI. Cobbler is

currently used under the hood, yet, migration to Ironic

is intended. Puppet is used for CM. Some features

comprise the automated discovery of nodes and the

possibility to perform pre-deployment checks.

JuJu

is an orchestration technology that is also

used for MAAS. As with MAAS, also the deployment

of OpenStack is speciﬁed in form of an orchestration

in a YAML ﬁle. Charms, classiﬁed by (Wettinger

et al., 2014) as environment-centric artifacts, deploy

the actual OpenStack services.

Packstack

provides Puppet modules for Open-

Stack projects. Using Puppet for CM, the various

OpenStack services can be deployed. Thus, some

OpenStack Bare Metal Provisioning (Ironic). http://wiki.

openstack.org/Ironic

Metal as a Service (MAAS). http://maas.io

http://wiki.openstack.org/Compass

http://crowbar.github.io

http://wiki.openstack.org/Fuel

http://jujucharms.com

http://wiki.openstack.org/Packstack

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

310

front-end deployment tools such as RDO (see below)

make use of Packstack. Currently, distributions based

on RedHat Package Manager (RPM) are supported.

RDO

is a web-based deployment tool based on

Foreman, a Ruby on Rails application and frontend for

the CM with Puppet. Therefore Packstack is used.

TripleO

is an exception to the CM-based solu-

tions. Instead of relying on such, TripleO aims at real-

izing the functionality using OpenStack’s own cloud

features for facilitating installation, management, and

operation. For this, a deployment cloud (a.k.a. under-

cloud) needs to be setup ﬁrst. Using Ironic workload

cloud(s) (a.k.a. overcloud(s)) are deployed. The de-

ployment and conﬁguration of nodes is realized using

Heat. For this golden images need to be prepared.

These consist of a base OS with elements on top (re-

sembles FAI class and proﬁle concept). During provi-

sioning a node will conﬁgure itself using the parame-

ters from a Heat Orchestration Template (HOT) that

constitutes the deployment plan. Finally, an overcloud

can be scaled using the Tuskar subproject.

3.3 Positioning and Contribution

Currently, there is neither a standard nor a common

datamodel for the conﬁguration of an OpenStack de-

ployment in a cloud DC. As a result, none of the

projects exposes its conﬁguration in a form that can

be used by other projects. This however would be in-

teresting in order to evaluate different frameworks and

avoid tool dependencies. TripleO – aiming at avoid-

ing any third party dependency for the deployment of

OpenStack – is a particular case. It is using HOT for

realizing the CM. This way, it decouples the conﬁg-

uration from the automated deployment. It may be

argued that HOT is an established format that other

tools could implement. Yet, this is not feasible, as it

dictates orchestration through Heat. Not only Heat

but also JuJu is an orchestration technology. In both

cases, therefore, conﬁguration needs to be expressed

in a particular syntax and way by experts leading to the

problems mentioned such as scattering and tangling.

MING in contrast truly decouples conﬁguration

from automated deployment technologies. It declar-

ativly permits the view-based modeling of DCs and

their deployments, facilitating SoC. As a result, stake-

holders that are not familiar with the used deployment

technologies and/or other concerns of the deployment

are supported as well. Similar in spirit with Cobbler

MING integrates with arbitrary tools and frameworks

(as also envisioned by Compass) through code genera-

tion.

http://rdoproject.org

http://wiki.openstack.org/TripleO

4 ABSTRACTING FROM

TECHNOLOGIES

MING aims at a tool agnostic, declarative speciﬁcation

of conﬁguration for realizing an IaaS deployment in a

cloud DC from bare machines. For this, conﬁgurations

from existing provisioning and deployment technolo-

gies have been sublimated using reverse model-based

engineering (MBE). That is, models are established

through abstraction. Given a valid deployment plan in

form of MAAS and OpenStack JuJu ﬁles, DC speciﬁc

values and repetitive code has been identiﬁed in a ﬁrst

step.

For capturing respective information in models, a

conceptual metamodel has been derived and templates

have been created in a next step. Finally, integration

with the target technologies was realized using code

generation. That is, the same code was generated

using the MBE approach. As a result, a conceptual

modeling layer has been established with sublimated

conﬁguration in form of models.

Modeling Cloud Datacenter Deployments (MING)

Default Models

Target Technologies (e.g., MAAS & JuJu)

Models

MING Textual Domain Specific Language (concrete DSL)

abstraction

conform to

corresponds to expressed in

defines

MING Metamodel (abstract DSL)

sublimation

MING Views (e.g., Datacenter and Nodes (cf. Fig. 1))

code generation

Templates

Figure 2: Overview of the MING Framework.

Figure 2 depicts the MING framework. As an in-

terface for populating, expressing, and representing

models, a textual DSL has been deﬁned for the MING

metamodel (i.e., abstract DSL). In order to support

SoC, distinct views permit the expression of differ-

ent aspects. One view, e.g., covers the DC related

information as depicted in the metamodel shown in

Figure 1. Other views capture networking, node as-

signments (e.g., to an aggregate), OpenStack speciﬁc

conﬁguration, and credentials.

For supporting convention over conﬁguration, de-

faults can be expressed in models too that are applied

to models in case of missing conﬁguration. Finally,

Sublimated Conﬁguration of Infrastructure as a Service Deployments - MING: A Model- and View-Based Approach for Cloud Datacenters

311

model transformation processes the (resulting) models

and generates code using templates.

5 IMPLEMENTATION

For realizing the MING prototype, the Eclipse Model-

ing Framework (EMF)

was chosen as a modeling

foundation. Xtext served for deﬁning the DSL and its

views and for obtaining a respective editor. Finally,

model transformations were implemented in Xtend.

For a better understanding of the approach and in

order to present some details, two artifacts (i.e., a code

generation and a DSL view) are explained.

nodes:

«FOR az : dc.azs»

«FOR rack : az.racks»

«FOR node : rack.nodes»

- name: «model.deployment.name»-«node.name»

«IF node.nodeType == NodeTypeName.CN»

tags: «getComputeAggregate(zones, node, az)»

«ELSEIF node.nodeType == NodeTypeName.SN»

tags: storage-«getCephPool(zones, node).name»

«ELSEIF node.nodeType == NodeTypeName.MN»

tags: api

«ELSEIF node.nodeType == NodeTypeName.NN»

tags: gateway-«getGatewayZone(zones, node).name»

«ELSE»

tags: standby

«ENDIF»

architecture: «node.arch»/generic

mac_addresses:

«FOR nic : getNICs(node)»

- «nic.mac»

«ENDFOR»

power:

type: ipmi

address: «getIPMI(node)»

user: «model.credentialsIPMI.username»

pass: «model.credentialsIPMI.password»

driver: LAN_2_0

«enrichWithIPs(node)»

«FOR nic : getNICs(node).filter[it.ip4 != null]»

sticky_ip_address:

mac_address: «nic.mac»

requested_address: «nic.ip4»

«ENDFOR»

Figure 3: Code Generation for MAAS nodes with Xtend.

Figure 3 depicts an excerpt from the model-to-text

(M2T) transformation for generating a MAAS con-

ﬁguration ﬁle. Three FOR loops iterate over all DC’s

availability zones, racks, and ﬁnally nodes. As a result

an entry is generated for every node containing all of

its MAC addresses and assigned IP addresses. The

latter are speciﬁed in a

sticky ip address

section.

Code generation assures the consistency between the

MAC addresses.

Please note that the same model can be processed

by a different template for supporting a different target

technology.

http://eclipse.org/modeling/emf

IaaS Deployment SongThrush @ MingDC8

OpenStack Liberty on Trusty

Compute

liveMigration

mtu 9000

Ceph

osdFormat btrfs

osdReformat

Percona

maxConnections 12345

Neutron

externalBridge "br-ext"

overlayNetType "gre vxlan"

l3_ha

l3_agents 2–4

mtu 9000

Heat

workers 8

hiddenTags "generated"

Figure 4: Deployment of OpenStack – DSL View.

For conﬁguring OpenStack various variables exist

for the different services. Using the DSL editor a user

proﬁts from code completion, syntax highlighting, and

validation. Figure 4 shows an example conﬁguration

view for the deployment of OpenStack services at a

DC using a referenced OS image for the bare machine

installation and a certain version of OpenStack.

Together with the other views (e.g., an instance of

the metamodel as shown in Figure 1) and the default

models information is complete for model transfor-

mation to take place. The current prototype supports

generation of JuJu YAML ﬁles for MAAS and Open-

Stack. For the sublimated conﬁguration, the ratio be-

tween the size of MING models and YAML code for

MAAS and JuJu yielded

27%

. That is, the models in

MING are nearly four times more compact than the

corresponding code as generated by the templates.

6 DISCUSSION

The model-based approach enables the utilization of

diverse technologies. Given availability of respective

templates, this enables evaluation of different deploy-

ment tools. That is, from the same models conﬁg-

urations are generated using the templates. This in

turn fosters a common datamodel for establishing a

standard for conﬁguring an IaaS deployment from bare

machines. With the separation of the models in distinct

views further beneﬁts can be leveraged:

Discovery of nodes and their components automat-

ically yields a certain view. Credentials as stored in

another view are generated initially if not set for a

certain deployment. In both cases parts of the over-

all conﬁguration are provided and the DSL user only

needs to focus on the other aspects of a deployment.

For a given DC it is possible to specify different

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

312

deployments. That is, while the physical setup (i.e.,

availability zones, racks, and nodes) as captured in one

view does not change, views related to the deployment

such as the assignment of nodes or the deployment and

conﬁguration of OpenStack services may be different.

Yet, only a part of the overall conﬁguration is adapted

and existing views can be reused avoiding software

clones. This way, deployments can be tested and the

differences between them can be described precisely

by comparing two models.

In case a different DC shall be deployed similarly,

it is possible to reuse views such as the conﬁguration

of OpenStack services. This eases the deployment of

multiple DCs with a tested conﬁguration.

The possibility to specify default conﬁguration op-

tions in models permits custom user-deﬁned defaults.

The fact that these are then applied on the views has

two major advantages: It simpliﬁes the models by

moving default conﬁguration options out of the views

making the ﬁles more compact. Also, it simpliﬁes code

generation by only processing the resulting model and

makes it independent from any (user-deﬁned) defaults.

Regardless of the beneﬁts of this model-based ap-

proach, it is always possible to continue work with the

output. Thus, MING does not introduce any depen-

dency in regard to the underlaying automation.

Not all ﬁne-grained conﬁguration options of the

bare machine provisioning or IaaS solution are re-

ﬂected in the MING metamodel. Thus, in case these

shall be lifted to the modeling layer, the metamodel

and the views need to be extended. In case multi-

ple technologies are supported using code generation,

certain features of one technology may not be sup-

ported by alternatives. For example, the deployment

of IaaS services may be realized using Kernel-based

Virtual-Machine (KVM) or Linux Containers (LXC).

In case such a conﬁguration option is speciﬁed but not

supported by a technology a fallback may be realized

during code generation. For early feedback this can

be addressed through validators in the DSL. That is,

when selecting an option that is not supported by some

technologies a warning is displayed in the DSL editor.

7 CONCLUSION

In this paper MING, a model-based approach, has been

presented for the tool agnostic, declarative conﬁgura-

tion of IaaS deployments in cloud DCs.

A textual DSL permits to describe such deploy-

ments from different view-points. Through code gen-

eration particular technologies for the automated in-

stallation and deployment of a base OS and OpenStack

as an IaaS solution are leveraged.

ACKNOWLEDGMENTS

The author would like to thank the extended Infrastruc-

ture Cloud team and in particular Tobias Brausen and

Thomas Oswald for valuable feedback and comments

and Mike Machado for proofreading.

REFERENCES

Andrikopoulos, V., Binz, T., Leymann, F., and Strauch, S.

(2013). How to Adapt Applications for the Cloud

Environment. Computing, 95:493–535.

Cerf, V. G. and Khan, R. E. (1974). A protocol for packet

network intercommunication. IEEE Transactions on

Communications, 22:637–648.

Chandrasekar, A. and Gibson, G. (2014). A comparative

study of baremetal provisioning frameworks. Tech-

nical Report CMU-PDL-14-109, Parallel Data Lab,

Carnegie Mellon University.

Droms, R. (1997). Dynamic Host Conﬁguration Protocol.

RFC 2131, The Internet Engineering Task Force.

artner, M., Lange, T., and R

uhmkorf, J. (1999). The fully

automatic installation of a Linux cluster. Technical

Report 379, Computer Science Department, University

of Cologne.

Intel Corporation (1999). Preboot Execution Environment

(PXE) Speciﬁcation Version 2.1. http://download.

intel.com/design/archives/wfm/downloads/pxespec.pdf

[accessed in March 2016].

Lange, T. (2010). 10 Jahre FAI Projekt. Technical Re-

port 603, Computer Science Department, University of

Cologne.

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

of Cloud Computing. Technical Report SP 800-145,

National Institute of Standards & Technology.

Sollins, K. R. (1992). The TFTP Protocol (Revision 2). RFC

1350, The Internet Engineering Task Force.

Weil, S. A., Brandt, S. A., Miller, E. L., Long, D. D. E.,

and Maltzahn, C. (2006). Ceph: A scalable, high-

performance distributed ﬁle system. In Bershad, B. N.

and Mogul, J. C., editors, 7th Symposium on Operating

Systems Design and Implementation, pages 307–320.

USENIX Association.

Wettinger, J., Breitenb

ucher, U., and Leymann, F. (2014).

Standards-Based DevOps Automation and Integration

Using TOSCA. In 7th IEEE/ACM International Con-

ference on Utility and Cloud Computing, pages 59–68.

IEEE.

Zimmermann, H. (1980). OSI Reference Model–The ISO

Model of Architecture for Open Systems Intercon-

nection. IEEE Transactions on Communications,

28(4):425–432.

Sublimated Conﬁguration of Infrastructure as a Service Deployments - MING: A Model- and View-Based Approach for Cloud Datacenters

313