University of Duisburg-Essen Paluno · 2013-12-16 · OpenStack: The Cloud OS echnicalT Report...

University of Duisburg-Essen

Paluno

Software Systems Engineering

Prof. Dr. Klaus Pohl

OpenStack: The Cloud OS- Technical Report -

Hasan Mohamed Ibou

Supervisor:Dr. Clarissa Marquezan

25.10.2013

OpenStack: The Cloud OSTechnical Report

Hasan Mohamed Ibou

Supervisor:

Dr. Clarissa Marquezan

Universiy of Duisburg-EssenPaluno - The Ruhr Institute for Software TechnologyGerlingstraÿe 1645127 Essen, [email protected]@paluno.uni-due.de

1

2

Abstract

This report covers OpenStack as an IaaS (Infrastructure as a Service) managementsystem in context of cloud computing. The goals of this study are: learn the basics ofcloud computing, learn more about OpenStack as a cloud OS (Operating System) andretrieve information and concert data out of OpenStack for the monitoring and opti-mizing of machines on both the physical and logical level. The researched informationsin this report should serve the goal of manipulating and monitoring the possibilitiesof a cloud under OpenStack and the entities of a cloud such as cloud-based applica-tions while considering the physical and the virtual level of the machines in order tooptimize each entity of the cloud system to get the cloud environment as a big picturerunning more e�ectively, e�ciently, and in the best case, automatically.

This document is structured as following: it starts with an introduction to cloudcomputing and OpenStack. It then investigates the linking of OpenStack to the ap-propriate cloud computing level. After combining both topics, it previews the corecomponents of OpenStack individually and mentions the important sub-componentsof the core components of OpenStack. The report is divided in three parts and endswith a conclusion previewing the results of this study.

Keywords: Cloud Computing, OpenStack, Cloud OS, IaaS-Management-System

3

Acknowledgment:

I would like to thank Dr. Clarissa Cassales Marquezan for the great help inwriting this document.

Preface

The aim of this record is to help everyone who is interested in learning aboutthe cloud OS �OpenStack� under a technical point of view. The report helpsgiving a basic introduction to cloud computing and OpenStack by describingthe components of OpenStack and the way the whole system works together.

Intended Audience

This technical report is for everyone who has a very basic background incomputer science and want to learn the basics of cloud computing and manip-ulating clouds with OpenStack.

4

Contents

1 Introduction to Cloud Computing . . . . . . . . . . . . . . . . . . 71.1 De�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Service Models of Cloud Computing . . . . . . . . . . . . . . . . 71.3 Types of Clouds and Cloud Comparison . . . . . . . . . . . . . . 8

1.3.1 Types of Clouds . . . . . . . . . . . . . . . . . . . . . . . 81.3.2 Cloud Comparison . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Introduction to OpenStack . . . . . . . . . . . . . . . . . . . . . 102.1 Infrastructure Management Systems (Stacks) . . . . . . . . . . . 102.2 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 The Project and The Goals . . . . . . . . . . . . . . . . . 102.2.2 Project Releases . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 Community and Users . . . . . . . . . . . . . . . . . . . . 11

2.3 Components of OpenStack . . . . . . . . . . . . . . . . . . . . . . 122.4 Installation Architecture of OpenStack . . . . . . . . . . . . . . . 13

2.4.1 Single Node . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Two and Multi Node . . . . . . . . . . . . . . . . . . . . 142.4.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Conceptual and Logical Architecture . . . . . . . . . . . . . . . 152.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Components of OpenStack . . . . . . . . . . . . . . . . . . . . . . 173.1 Dashboard - Horizon . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Compute - Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 nova-api . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 nova-api-metadata . . . . . . . . . . . . . . . . . . . . . . 193.2.3 nova-compute . . . . . . . . . . . . . . . . . . . . . . . . 193.2.4 nova-schedule . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.5 nova-conductor . . . . . . . . . . . . . . . . . . . . . . . . 203.2.6 nova-network . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.7 nova-novncproxy . . . . . . . . . . . . . . . . . . . . . . . 203.2.8 nova-xvpnvncproxy . . . . . . . . . . . . . . . . . . . . . . 203.2.9 nova-consoleauth . . . . . . . . . . . . . . . . . . . . . . . 203.2.10 nova-dhcpbridge . . . . . . . . . . . . . . . . . . . . . . . 203.2.11 nova-console . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.12 nova-cert . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.13 euca2ools . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.14 nova-objectstore . . . . . . . . . . . . . . . . . . . . . . . 213.2.15 nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.16 nova-manage . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.17 The queue . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.18 SQL database . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Object Store - Swift . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Proxy server (swift-proxy-server) . . . . . . . . . . . . . . 233.3.2 Account servers . . . . . . . . . . . . . . . . . . . . . . . . 23

5

3.3.3 Container servers . . . . . . . . . . . . . . . . . . . . . . . 233.3.4 Object servers . . . . . . . . . . . . . . . . . . . . . . . . 233.3.5 Other processes . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Image Store - Glance . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1 glance-api . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2 glance-registry . . . . . . . . . . . . . . . . . . . . . . . . 243.4.3 A database . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.4 A storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.5 Other processes . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Identity - Keystone . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.1 keystone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 Network - Quantum . . . . . . . . . . . . . . . . . . . . . . . . . 253.6.1 quantum-server . . . . . . . . . . . . . . . . . . . . . . . . 263.6.2 plug-ins and agents . . . . . . . . . . . . . . . . . . . . . . 26

3.7 Block Storage - Cinder . . . . . . . . . . . . . . . . . . . . . . . . 263.7.1 cinder-volume . . . . . . . . . . . . . . . . . . . . . . . . 263.7.2 cinder-api . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7.3 cinder-scheduler . . . . . . . . . . . . . . . . . . . . . . . 27

3.8 Summary and Conclusion . . . . . . . . . . . . . . . . . . . . . . 27

6

List of Figures

1 Cloud computing services and layers [1, 2] . . . . . . . . . . . . . 82 Di�erence between basic types of Clouds[1, 2] . . . . . . . . . . . 93 OpenStack Releases [5, 6] . . . . . . . . . . . . . . . . . . . . . . 114 Components of OpenStack [6] . . . . . . . . . . . . . . . . . . . 135 OpenStack Hardware Recommendations for Production[6] . . . . 146 Logical Architecture of OpenStack [6] . . . . . . . . . . . . . . . 167 OpenStack Dashboard [6] . . . . . . . . . . . . . . . . . . . . . . 178 Functions of Compute Sub-Components [6] . . . . . . . . . . . . 199 Database Schema [6] . . . . . . . . . . . . . . . . . . . . . . . . . 22

1 Introduction to Cloud Computing 7

1 Introduction to Cloud Computing

This part12gives an introduction to cloud computing by answering the questions:What is cloud computing?, What are the service models of cloud computing?,and What are the deployable arts of clouds?

1.1 De�nition

Cloud computing[2] revolutionizes the services and business domain. It opensup big opportunities for research and production with its powerful featuressuch as scalability, performance, and reduced upfront investments. Especially,pay-as-you-go and service-orientation are important functionalities for businesstoday. Cloud computing uses virtualization as a key enabling technology thatis simulating logical hardware resources from physical resources[3]. But what iscloud computing? The National Institute of Standards and Technology (NIST)has the following de�nition for cloud computing[2]:

�Cloud computing is a model for enabling ubiquitous, convenient,on - demand network access to a shared pool of con�gurable com-puting resources (e.g., networks, servers, storage, applications, andservices) that can be rapidly provisioned and released with minimalmanagement e�ort or service provider interaction.�

1.2 Service Models of Cloud Computing

Cloud Computing provides its resources as services. There are currently sixprovided services[2]: Infrastructure as a Service (IaaS), Network as a Service(NaaS), Platform as a Service (PaaS), Identity and Policy Management as aService (IPMaaS), Data as a Service (Daas), and Software as a Service (SaaS).These services �ll into three main cloud computing layers, which are: hardware,system, and application. Figure 1 shows the services with the associated layers.

1 Main source of this document: o�cial OpenStack documentaries2 Considered version: OpenStack �Grizzly�


Service \ Layer Hardware System Application Main Service

Software as a Service (SaaS) x

SaaSData as a Service (Daas) x

Identity&Policy Manage as a Service (IPMaaS) x

Platform as a Service (PaaS) x Paas

Network as a Service (NaaS) xIaaS

Infrastructure as a Service (IaaS) - logical - x

Fig. 1: Cloud computing services and layers [1, 2]

The mentioned six services could be abstractly grouped in three main services[1]:

1. Infrastructure as a Service (IaaS): consists of hardware (such asCPUs, RAMs, Storage, and Network), and logical infrastructure (suchas virtual machines VMS).

2. Platform as a Service (PaaS): provides frameworks and operatingsystems for software development.

3. Software as a Service (SaaS): contains applications running on thelogical layer.

Each of these three layers could be provided separately by di�erent cloud serviceproviders such as Amazon or IBM and then combined to �t the organization'sneeds. However, all of them could be provided as a �package of services� by asingle cloud provider such as Google, for example[1].

1.3 Types of Clouds and Cloud Comparison

This section explains the di�erent types of clouds based on the di�erent imple-mentations of clouds with the aspects that in�uence the decision of choosing acloud type. After that, the section makes a comparison between the basic typesof clouds in order to better understand these types.

1.3.1 Types of Clouds

The di�erent implementations of clouds depend on the needs and purposes of acloud. The di�erent implementations cause di�erent types of clouds. The futureneeds and use of the cloud - whether in research or production - determines thecloud's type. Also cost, security, and customariness widely in�uence the decisionof choosing the correct cloud type wildly[1]. The main types of clouds are publicand private clouds. There are di�erent combinations of private and public cloudssuch as hybrid, and community clouds. The most common types of clouds arenamed below[1][4]:

I Public Clouds: cloud resources are open for public use.

I Private Clouds: cloud resources are owned or leased by a single organiza-tion.


I Hybrid Clouds: composition of di�erent types of clouds to enable a service.

I Community Clouds: cloud resources are shared by several organizations.

I Virtual Private Clouds (VPC): private clouds over public ones via vpn.

After mentioning the types of clouds, next is a short comparison between public,private, and virtual private clouds.

1.3.2 Cloud Comparison

The public and private clouds are the basic types of clouds[1]. The other typesof clouds could be delivered from public and private clouds as well as virtualprivate clouds. The main di�erences between public, private, and virtual privateclouds is shown in �gure 2 [2].

Aspect \ Cloud Public Private Virtual Private

Cost low high lowCustomization no yes yes

Privacy low high high

Fig. 2: Di�erence between basic types of Clouds[1, 2]

Public clouds have generally low cost as an advantage, but they are neithersecure nor customizable. On the other hand, private clouds are secure and highlycustomizable but they have pretty high cost. Virtual private Clouds combinethe advantages of both public and private clouds by providing more securityand customization ability with low cost.

The decision of choosing the right cloud must be very precise, which is whythe design of clouds is very important process before purchasing infrastructure[1,2]. Every aspect and possible use of the cloud must be planned and consideredcorrectly before the implementation phase. This simpli�es achieving the purposeof the cloud correctly.

1.4 Summary

This part has mentioned a de�nition of cloud computing, a description of re-sources of cloud computing, and has summarized them in three main services:Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Softwareas a Service (SaaS). It concludes with a di�erentiation between di�erent typesof clouds and some important aspects to consider when choosing a cloud type.

2 Introduction to OpenStack 10

2 Introduction to OpenStack

This part names di�erent infrastructure management software systems such asOpenNeubla or Eucalyptus. It then reviews OpenStack by giving basic infor-mation about the goals of the OpenStack project, a list with versions of Open-Stack, examples of universities and companies where OpenStack is currentlydeployed, and views both the conceptual and logical architecture of the Open-Stack projects. Finally, it lists the components of OpenStack and shows thedi�erent installation architectures of OpenStack with the recommended hard-ware requirements.

2.1 Infrastructure Management Systems (Stacks)

There are di�erent software and systems to manage cloud Infrastructure anddata centers generally on an IaaS (Infrastructure as a service) level. Thesesystems are often informally called Stacks. Some of these Stacks are open-sourceand some are commercial. Stacks deliver implementations for public, private, oranother type of clouds. Examples of current cloud infrastructure systems are:HP CloudSystem, IBM CloudBurst, ElasticStack, OpenStack, etc. The mostused open-source alternatives are: OpenStack, OpenNebula and Eucalyptus.

The development of OpenNeubla and Eucalyptus has started in the middle of2008, while the development of OpenStack has started in late 2011. OpenStackhas a large community and support of several big companies and organizationswhich lead to relatively rapid development, despite the late start of develop-ment. On October 17, 2013, �Havana� is scheduled to be be published as theeighth release of OpenStack. One of the OpenStack project objectives is: �be-ing the ubiquitous software choice for building cloud infrastructures�. Actually,OpenStack is currently achieving the objective of becoming a standard choicefor cloud infrastructure in many research and production organizations. Thenext section gives a more detailed information on this.

2.2 OpenStack

This section de�nes OpenStack, names the goals of the OpenStack project,lists the releases of OpenStack, and gives an overview of organizations whereOpenStack is currently deployed.

2.2.1 The Project and The Goals

The OpenStack Project is [6] an open-source cloud computing platform forpublic and private cloud. The Project focuses initially on[5] Infrastructure asa Service (IaaS) o�ering. The main objective of the OpenStack project is: [6]�to produce the ubiquitous Open Source Cloud Computing platform that willmeet the needs of public and private clouds regardless of size, by being simple toimplement and massively scalable� which derives the goals of OpenStack: beinga standard software for cloud infrastructure, simplicity, and scalability. Embrace


of openness is [5] a core value behind the project with both open standardsand open code. OpenStack has been released under the Apache 2.0 license.OpenStack also encourages standard through the OpenStack API. Rackspace3

and NASA4 [5] have originally started the OpenStack project in September 2012.Companies like [6] AT&T, Rackspace, HP, IBM, Canonical, Red Hat, SUSE,Cisco, Dell, and Intel are only some examples of more than 1505 supportercompanies with a very active and large community of contributers.

2.2.2 Project Releases

The OpenStack project has a large and active global community, leading torapid development. The �rst version �Austin� was released on the October 21,2010 and the release date of the new release �Havana� should be the October 17,2013. October 21, 2010. Figure 3 lists the releases of the OpenStack project.

Release Name Release Date

Havana 17.10.2013Grizzly 04.04.2013Folsom 27.09.2012Essex 05.04.2012Diablo 22.09.2011Cactus 15.04.2011Bexar 03.02.2011Austin 21.10.2010

Fig. 3: OpenStack Releases [5, 6]

2.2.3 Community and Users

The large and extremely active community [5] leads to rapid development asseen in 2.2.2. The community consists of many developers, translators, andsupporters from both academic and enterprise �eld. The OpenStack projecthas active forums, a well structured wiki, clear documentations, mailing listsand, IRC-channel.

The users of OpenStack are [5] researches, corporations, service providers,or data centers who are looking to deploy large-scale cloud deployments forprivate or public clouds. Currently, there are [6] 1216 organizations that relyon OpenStack such as Harvard University and CERN7 from the research areaor PayPal and Cisco in in the �eld of enterprise.

3 Hosting organization in USA4 Space agency in USA5 full list: http://www.openstack.org/foundation/companies/6 http://www.openstack.org/user-stories/7 The European Organization for Nuclear Research


2.3 Components of OpenStack

There are currently seven core components [6] of OpenStack: Compute, ObjectStorage, Identity, Dashboard, Block Storage, Network, and Image Service. Eachof them has a code name. Below, there is a short description for each component.

I Compute (codenamed "Nova"): provides virtual computing serverson demand.

I Object Store (codenamed "Swift") : allows storing and retrieving�les.

I Identity (codenamed "Keystone"): provides authentication and au-thorization for other OpenStack services and also provides a catalog ofservices within a particular OpenStack cloud.

I Dashboard (codenamed "Horizon"): provides a web-based GUI (Graph-ical User Interface) for all other OpenStack services. Dashboard allowsmanaging of virtual machines (VMS) manipulation operations.

I Block Storage (codenamed "Cinder"): supplies a block storage toguest VMS.

I Network (codenamed "Quantum"): provides Network as a Service(NaaS)between devices managed by other OpenStack services (mostly Compute).

I Image (codenamed "Glance"): provides a catalog and repository forvirtual disk images that are mostly used in Compute.

Figure 4 shows the relationship between the core components of OpenStack.


Fig. 4: Components of OpenStack [6]

2.4 Installation Architecture of OpenStack

OpenStack uses a share-nothing policy and messaging-based architecture[6] thatallows a �exible architectures. Each of the components (or widely sub compo-nents) is runnable on di�erent server. The components are connected to eachother via HTTP (Hypertext Transfer Protocol) and AMQP (Advanced Mes-sage Queue Protocol). That means that each component could separately workon a di�erent machine. There are basically three types of possible installationarchitectures of OpenStack.

I Single node: one server runs all the components. Mostly used for practiceand learn purposes.

I Two nodes: cloud controller server (all components of: compute - withoutthe sub-component nova-compute, Image, Object Store, authentication,and Dashboard services) and another server runs only the sub-componentnova-compute

I Multiple nodes: can be achieved by simply adding another nova-computeserver to the two node architecture and copying the nova.conf �le to thenew nova-compute server.

2.4.1 Single Node

The single node architecture is useful for earning and practicing purposes. It isan easy and very fast way to get hands on OpenStack quickly without deeper


learning about the con�guration and installation process for each component.All that is needed is a Linux-based server8 and a DevStack 9 installation. De-vStack can be downloaded at http://devstack.org.

2.4.2 Two and Multi Node

The single node architecture is only try-oriented and is not recommended forproduction use at all. The production architecture typically contains two (ormore) nodes (at least 2 servers and one client). This architecture is of course�exible and highly scalable for production needs. It also allows the three copiesconcept of having three data backups by connecting to a database.

2.4.3 Requirements

Figure 5 shows the recommended hardware requirements for OpenStack forproduction purposes. Minimum hardware requirements for Single Node (testenvironment) are: dual-core processor with 2 GB of RAM and two networkcards (one could be virtual). A Controller Node in a Two Node environmentruns network, volume, API, scheduler, and image services while Compute Noderuns the VMS. In Cloud Controller Node: a quad core server with 12 GB ofRAM would be more than su�cient and two NICs are recommended but not re-quired. In Compute Node: AMD processor with SVM (Secure Virutal MachineMode also called AMD-V) extensions or Intel processor with VT (virtualizationtechnology) extensions.

Node Recommended Hardware

Cloud Controller

Processor: 64-bit x86Memory: 12 GB RAMDisk space: 30 GB (SATA, SAS or SSD)Volume storage: two disks with 2 TB (SATA)Network: one card with 1 Gbps NIC10

Compute

Processor: 64-bit x86Memory: 32 GB RAMDisk space: 30 GB (SATA)Network: two cards with 1 Gbps NICs

Fig. 5: OpenStack Hardware Recommendations for Production[6]

Hint: The idea of putting this section directly at this place is to give anearly chance to get hands on OpenStack easily and fast without the need to godeeper into the report using DevStack. This could be useful for a reader whowant just to use OpenStack in order to test the environment or test applicationson it.

8 Most used: Ubuntu or Fedora server cloud edition9 DevStack is an opinionated script to quickly create an OpenStack development environ-

ment


There is an easy way to test an elastic web application on the cloud usingTryStack (trystack.org) that allows trying the application on a pre-installedOpenStack environment with no need to install OpenStack on own machines.

2.5 Conceptual and Logical Architecture

The goal of OpenStack is [6] to deliver a massively scalable cloud OS (operatingsystem). The design used [6] to achieve this is service-orientated design as shownin �gure 4. That means that each component of OpenStack is [6] designed(on a conceptual level) as a divided service which o�ers and consumes fromother services. The services collaborate [6] with each other and are integratedthrough application programming interfaces (APIs). These APIs are [6] mostlythe same as end user APIs. This conceptual design allows [6] an implementationof selected services if other services are not needed.

Modules, on the other hand (and on a logical level), are [6] organized accord-ing to the function they implement. The modules are classi�ed [6] according totheir type. There are [6] four types of modules used in the OpenStack project:

daemon: runs as a daemon (background process),

script: a script run by an external module when some event happens,

client: a client for accessing the Python bindings for a service and

CLI: a Command Line Interpreter.

Figure 6 shows the logical architecture of the OpenStack project.


Fig. 6: Logical Architecture of OpenStack [6]

2.6 Summary

Part two has named di�erent infrastructure management systems (or Stacks)such as OpenNebula. After that, it has given an overview of the OpenStackproject goal, which is: becoming a standard software for cloud infrastructurewith focus on simplicity and scalability. It has then shown the available releasesand the active community behind the project. This part has also answered thequestion of where OpenStack is currently deployed and used. After that, it wasshown that the design of OpenStack is service-oriented and the types of modulesare: daemon, script, client, and CLI (Command Line Interpreter). At the endof this part, the single-node and multi-node have been presented as main instal-lation architectures of OpenStack with a look on the recommended hardwarerequirements for each of both architectures. This part concludes with giving anadvice on getting OpenStack fast using DevStack or testing web applications ona ready-to-use OpenStack environment using TryStack.

3 Components of OpenStack 17

3 Components of OpenStack

This part focuses on the core components of OpenStack without mentioningother OpenStack projects (such as OpenStack - Ceilometer a Metering Project).This part reviews the core services of OpenStack separately by naming thesub-components and entities for each core service. The key features of thecomponents will also be covered to give a better description for each component.his part concludes with the results of this report.

3.1 Dashboard - Horizon

Dashboard is a web application that provides an end user and administratorinterface in order to manage other OpenStack services. Dashboard is deployedvia mod_wsgi (python) in Apache. Dashboard basically represents the providedinteractions with other OpenStack APIs. Dashboard is also customizable fordi�erent providers and has a database that has a small capacity but relies onother data services. Dashboard allows managing instances (VMS), images, keypairs, volumes, containers, etc. The console of an instance (VM) could be alsoaccessed directly from the dashboard. Figure 7 shows the dashboard interfacethat can can be accessed through the local host address within a web browser.

Fig. 7: OpenStack Dashboard [6]


Some examples [7] of Dashboard features:

I User and Security Management: manipulation of users, groups (tenants),roles, projects, key pairs, assigning �oating IPs, etc.

I Instance Management: creating, terminating, launching, starting, stop-ping of instances or accessing the consoles of the launched instance.

I Volume & Network Management: attaching volumes or creating networkresources.

I Flavor Management: managing of di�erent �avors (hardware templates),adjusting hardware con�gurations for speci�c instances or de�ning newones.

I Image and Volume Management: editing or deleting images, creating vol-umes and snapshots (save a state of a VM for later use).

I Object Store Management: creating, deleting containers and objects.

3.2 Compute - Nova

Compute is the heart of OpenStack. It manages all the activities associated withthe life cycle of a VM instance. Compute combines di�erent processes togetherto execute user requests into running virtual machines. Compute manages com-pute resources, networking, authorization, and other core processes in the cloud.However, Compute does not provide any virtualization by itself; instead, it usesan API to interact with hypervisors. The API of Compute is compatible withthe EC2 API of Amazon Web Services.

Some features of OpenStack Compute:

I Instance life cycle management

I Compute resources management

I Network and Authorization

I REST-based API

I Hypervisor independence.

The sub-components of Compute are shown together with the function for eachsub-component in Figure 8.


Sub-Component Functionnova-api API

nova-api-metadata API

nova-compute Computing Corenova-schedule Computing Corenova-conductor Computing Core

nova-network Networking for VMSnova-dhcpbridge Networking for VMS

nova-consoleauth Console Interfacenova-novncproxy Console Interfacenova-console Console Interface

nova-xvpnvncproxy11 Console Interfacenova-cert Console Interface

nova-objectstore Image Managementeuca2ools Image Management

nova CLI12 & Interfacenova-manage CLI & InterfaceThe queue CLI & Interface

The SQL database CLI & Interface

Fig. 8: Functions of Compute Sub-Components [6]

3.2.1 nova-api

basically deals with end user API requests. The nova-api supports OpenStackCompute API, Amazon's EC2 API, and a special admin API.

3.2.2 nova-api-metadata

Accepts meta data requests from instances. The nova-api-metadata can onlybe used with an multi-node architecture.

3.2.3 nova-compute

A main worker daemon (background process) that creates and terminates VMinstances via hypervisor APIs. The nova-compute accepts actions from thequeue and performs system commands while updating the states in a database.


3.2.4 nova-schedule

The nova-schedule takes a virtual machine instance request from the queue anddetermines on which compute server host this request should run.

3.2.5 nova-conductor

A new module added to the Grizzly release deals with the database accessof nova-compute. The nova-conductor eliminates the direct accesses to thedatabase made by nova-compute for security and upgrade aspects. The nova-

conductor should be deployed in di�erent node where nova- compute is deployed.

3.2.6 nova-network

The nova-network is a worker daemon that accepts networking calls from thequeue and performs network-oriented tasks. This functionality is being migratedto OpenStack Networking.

3.2.7 nova-novncproxy

A daemon for providing a proxy for accessing running instances through a VNCconnection. The nova-novncproxy supports browser-based novnc clients.

3.2.8 nova-xvpnvncproxy

A daemon is a proxy for accessing running instances through a VNC connec-tion. The nova-xvpnvncproxy supports a Java client speci�cally designed forOpenStack.

3.2.9 nova-consoleauth

A daemon for authorizing user's tokens that console proxies provide. The nova-

consoleauth is needed for running the console proxies.

3.2.10 nova-dhcpbridge

The nova-dhcpbridge is a script for tracking and recording IP addresses in adatabase using dnsmasq's dhcp-script. The same functionality with di�erentscript is also provided by OpenStack Networking.

3.2.11 nova-console

An old daemon which is no longer used with the Grizzly release. The nova-

xvpnvncproxy is used instead.

3.2.12 nova-cert

A daemon to manage x509 certi�cates.


3.2.13 euca2ools

A client and not provided by OpenStack itself but euca2ools can be supportedby OpenStack. It is a set of CLI (command line interpreter) commands formanaging resources of the cloud. 13

3.2.14 nova-objectstore

A daemon that provides an interface in S3 (a programming language). Thenova-objectstore daemon is used for registering images in the image managementservice. The nova-objectstore translates the requests of euca2ools from s3 intoOpenStack Image requests.

3.2.15 nova

A client that enables submitting the administrator's or user's commands.

3.2.16 nova-manage

A client for submitting administrator commands.

3.2.17 The queue

A central hub for passing messages between daemons. Usually implementedwith RabbitMQ, it is possible with any AMPQ such as Apache Qpid or ZeroMQ.

3.2.18 SQL database

Stores build-time and run-time states of instances, networks, and projects. The-oretically, any database with an SQL-Alchemy is supported by OpenStack Com-pute, but currently sqlite3, MySQL, and PostgreSQL are widely used. Someimportant tables are describes below.

Tables of Nova-DB:

networks: Information about networks de�ned by Compute such as vpn addressor gateway.

instances: Describes VM-oriented information such like state, location, or ad-dress of a VM.

�xed_ips: Allocating and assigning of �xed addresses to VMS in a network.

�oating_ips: Allocating and assigning of �oating addresses to VMS in a network.

volumes: Representation of volumes attached to VMS.

projects: Information about projects including project manager.

13 For more information see http://www.eucalyptus.com/eucalyptus-cloud/documentation/2.0


services: Registered services and the current state of each service

auth_tokens: Mapping of API request with users

key_pairs: Pair keys for SSH connections

users: Contains information about users containing admin privileges

Fig. 9: Database Schema [6]

Schema: The schema of tables of nova-DB visualizes the tables and describesthe relationships between them. The schema is shown in �gure9. A detailed


list14 of the tables and attributes is added to the Appendix.Compute turns user commands to VMS with the help of di�erent APIs,

computing cores, command line interpreters, console Interfaces, and other Open-Stack services and interfaces. These subcomponents of Compute interacts witheach other to provide runnable and accessible virtual machines in the cloud.

3.3 Object Store - Swift

Object Store provides [7] a distributed and consistent virtual object store (�lesand containers) service for OpenStack. Object Store is like Amazon Web Ser-vices - Simple Storage Service (S3). The Object Store stores objects distributedacross nodes, has built-in redundancy and fail-over management, is extremelyscalable, and is capable of archiving and media streaming. The architecture ofObject Store is [6] distributed to prevent any failure and to scale horizontally.

Some features [7] of OpenStack Object Store:

I Large Storage of (large)objects

I Redundancy of data

I Archiving and media streaming capability

I Data container for VMS and cloud applications

I Security, backup, and scalability

Object Store consist of the following sub-components:

3.3.1 Proxy server (swift-proxy-server)

The swift-proxy-server accepts [6] user requests via Object Store API or justHTTP, accepts �les uploading and meta data modi�cations, and listens to webbrowsers to serve �les.

3.3.2 Account servers

Account servers serve and manage [6] accounts de�ned within Object Store.

3.3.3 Container servers

Container servers serve and manage [6] containers (folders) mapping withinObject Store.

3.3.4 Object servers

Object servers serve and manage [6] �les in Object Store.

14 https://docs.google.com/spreadsheet/ccc?key=0AsUHVTZg__ridEE3cjdrTWZaRGxtSXd0dVRUT0ZsdlE&hl=en_US#gid=0

https://docs.google.com/spreadsheet/ccc?key=0AsUHVTZg__ridEE3cjdrTWZaRGxtSXd0dVRUT0ZsdlE&hl=en_US#gid=0


3.3.5 Other processes

Periodic processes with housekeeping tasks such as [6] consistency, availabilitystate, auditors, updaters, and reapers. Authentication is handled throughWSGI(Web Server Gateway Interface) middle ware OpenStack Network.

The OpenStack Object Store generally manipulates and manages the datain the OpenStack project through several servers such as object, container,account, and proxy servers. Object Store uses other processes to ensure consis-tency and availability and is accessible through Object Store API or HTTP.

3.4 Image Store - Glance

Image Store handles and manages the images used by the VMS. Image Storealso has a central role in the IaaS big picture. It accepts API requests fromusers or OpenStack Compute and stores its �les in Object Store.

Some features [6] of OpenStack Image Store:

I Image and image status Identifying

I Image registering

I Image meta data and Image retrieving

Image Store has the following [6] sub-components:

3.4.1 glance-api

The glance-api accepts [6] image API calls for image discovery, retrieval, andstorage.

3.4.2 glance-registry

The glance-registry stores, processes, and retrieves [6] meta data about images(size, type, etc.).

3.4.3 A database

A database to store [6] image meta data. As in other OpenStack components itis freely selectable but MySQL or SQlite are the mostly used.

3.4.4 A storage

A storage for the actual image �les. Object Store is the default image repository[6] but this is con�gurable. The Image Store project also supports normal �lesystems, RADOS, Amazon S3, and HTTP (some of these choices are limited toread-only).


3.4.5 Other processes

Periodic processes to support [6] caching, consistency and availability.The Image Store project delivers and manages image service to the Open-

Stack project. It checks, identi�es, and registers VM images. It accepts userand Compute calls via API and stores their �les in OpenStack Object Store bydefault.

3.5 Identity - Keystone

The OpenStack Identity provides [6] an integration service for policy, catalog,token, and authentication in the OpenStack project. Identity handles API re-quests from other internal or external services and provides con�gurable cata-log, policy, token, and identity services. For each sub-service provides Identitya backend to allow di�erent uses of this sub-service. The widely used backendsare LDAP, SQL, and Key Value Stores (KVS). The Identity project is mostlyused for authentication of other OpenStack services.

Some features [7] of OpenStack Identity:

I Provides information about user type.

I Managing the access to other OpenStack services.

The OpenStack Identity have a core sub-component which is:

3.5.1 keystone

The keystone deals with [6] the API requests of other OpenStack services.The Identity project manages the authentication inside the OpenStack project

using an API and provides several standard backends such as LDAP, SQL, orKey Value Stores.

3.6 Network - Quantum

Network manages [6] the network connectivity within the OpenStack project.The Network service is needed and used by other OpenStack services and espe-cially OpenStack Compute. The Network service is con�gurable because of theplug-in architecture.

Some features [7] of Network:

I Network is �exible to achieve di�erent needs of applications.

I Managing di�erent IP addresses (static, dynamic, and �oating).

I Provides de�ning user networks.

I Supporting extended network services such as Intrusion Detection Systems(IDS), �rewalls, and VPNs.

The main sub-components of the OpenStack Network are:


3.6.1 quantum-server

The quantum-server deals [6] with the API requests. It routes the API requestto the correct plug-in.

3.6.2 plug-ins and agents

The plug-ins and the agents in Network execute [6] the actual networking taskssuch as porting, creating (sub)networks, and IP addressing). The common usedagents in Network are layer 3 (Dynamic Host IP addressing.

Network provides and manages the networking tasks in OpenStack. Networkdeals primarily with Compute to provide network resources to the VMS. TheNetwork supports di�erent plug-ins and agents for: Cisco virtual and physicalswitches, Nicira NVP, NEC OpenFlow, Open vSwitch, Linux bridging, and theRyu Network Operating System.

3.7 Block Storage - Cinder

Block Storage OpenStack project provides [6] storage (volume) as a service forthe OpenStack Compute. In previous versions, this used to be done via nova-volume in Compute. Block Storage separates the block storage that was partof OpenStack Compute (nova-volume) into its own service. The API of BlockStorage deals with requests for the manipulation of volumes or snapshots.

Some of the features [7] of Block Storage:

I Integration with Compute

I Performance with no central databasing

I Unlimited storage

The main sub-components of OpenStack Block Storage are:

3.7.1 cinder-volume

The cinder-volume executes, reads, and writes [6] operations to a database ofBlock Storage to update states of volumes or snapshots. The cinder-volume alsointeracts with some other processes (for example, cinder-scheduler) through amessage queue just like other OpenStack services that interact with each otheror with other sub-services of OpenStack. The cinder-volume supports otherstorage services (through drivers) such as IBM, SolidFire, NetApp, Nexenta,Zadara, linux iSCSI, etc.

3.7.2 cinder-api

The cinder-api basically deals [6] with the API requests and delivers them tocinder-volume which executes them.


3.7.3 cinder-scheduler

The cinder-scheduler is a daemon that chooses [6] the optimal provider nodeon which to create the needed volume. The cinder-scheduler works like nova-

scheduler (Compute) or OpenStack schedulers.The Block Storage OpenStack project mainly provides volume to VMS cre-

ated by Compute and primarily interacts with it or with other services via anAPI. The Block Storage service supports other storage services via drivers suchas IBM, SolidFire, NetApp, and many others.

3.8 Summary and Conclusion

Cloud computing is getting more important for both research and production�elds. As discussed in part one, cloud computing brings powerful features withit such as scalability, performance, and reduced upfront investments, especiallythe pay-as-you-go concept and the service-orientation trend. The six cloud com-puting resources mentioned in part one have been classi�ed in three main layers:Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Softwareas a Service (SaaS). The most used clouds currently are public and privateclouds. As a combination of public and private clouds other clouds could bedelivered by, for example, virtual private clouds. Because clouds are getting soimportant nowadays, the cloud management systems are also becoming impor-tant for their capability to manage and monitor the clouds. The second partof this report has previewed di�erent cloud infrastructure management systemssuch as OpenNebula. These systems are associated to the IaaS layer in cloudcomputing as discussed in part one. OpenStack has been introduced in parttwo as an example of a cloud OS. The reason to choose OpenStack is the ef-fort behind the project to standardize the system in order to become the bestcloud OS available, which basically is one of the OpenStack project goals nextto simplicity and scalability as covered in part two. With eight releases between2010 and 2013, OpenStack is actually achieving its goals with the support of ahuge community of research, commercial, and open source organizations. Afterdiscussing the OpenStack project and its main goals, this report has introducedthe core components of the system in a technical point of view starting with thedescription of the core components of OpenStack: Dashboard, Compute, ObjectStore, Image Store, Identity, Network, Block Storage and ending with namingthe subcomponents of each of them and mentioning the main types of modulesused in OpenStack which are: daemon, script, client, and CLI (Command LineInterpreter). The third part has also discussed the features of these componentsand how the components can work together.

In the appendix, a Compute data model is presented as an example of thedata structure used in building OpenStack.


References

[1] Qi Zhang, Lu Cheng and Raouf Boutaba: Cloud Computing state of the artand research challanges (2010)

[2] Minqi Zhou, Rong Zhang, Dadan Zeng, Weining Qian: Services in the CloudComputing Era-A Survey (2010)

[3] Mahjoub, Mdha�ar, Ben Halima, Jmaiel: A comparative study of the cur-rent Cloud Computing technologies and o�ers (2011)

[4] Dana Petcu: Invitation to Journey in the Era of Cloud Computing (2012)

[5] Ken Pepple: Deploying OpenStack (2011)

[6] o�cial OpenStack documentaries and website

[7] Atul Jha, Johnson D, Kiran Murari, Murthy Raju, Vivek Cherian, YogeshGirikumar: OpenStack Beginner's Guide v3.0, 7 (2012)

Appendix: Data Model of Compute database

Model Field Type Attr Short Description ExampleService id Integer PK Unique Id 1,2...

host String running host name localhost

binary String type of service nova-compute

topic String AMQP topic name compute-host1

report_count Integer Not Null, Default 0 number of "report_state" called

disabled Boolean Default False disable flag

availability_zone String default nova service's zone nova

ComputeNode id Integer PK Unique Idservice_id Integer relation Service(disabled = false) Service reference Id

vcpus Integer num of vcpu 4

memory_mb Integer memory size by mb 2048

local_gb Integer local disk size by gb 40

vcpus_used Integer num of used vcpu 2

memory_mb_used Integer size of used memory by mb 1024

local_gb_used Integer size of used local disk by gb 20hypervisor_type Text name of hypervisor libvirt

hypervisor_version Integer 1

cpu_info Text

Certificate id Integer PK Unique Iduser_id String certificate's user shida

project_id String certificate's project dev project

file_name String public key file name newcerts/inbound.pem

Instance id Integer PK, Auto Increment Unique Id

name String instance name i-XXXXXX, i-XXXXXX-rescure

user_id String instance owner user shida

project_id String instance owned project dev projectimage_ref String referenced image id ami-xxxxxxxx

kernel_id String referenced kernel image id aki-xxxxxxxx

ramdisk_id String referenced ramdisk image id ari-xxxxxxxx

server_name String name represented OSAPI new-server-test

launch_index Integer index of launch sequence

key_name String keypair name mykey

key_data Text public key fingerprint 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

power_state Integer code of power state

vm_state String value of vm state

task_state String value of instance task state

memory_mb Integer userd memory 1024

vcpus Integer used vcpu 2

local_gb Integer used local disk 20

hostname String running host name

host String reference of ComputeNodeinstance_type_id Integer reference for InstanceTypes

user_data Text instance user_data

reservation_id String reservation id r-xxxxxx

scheduled_at DateTime time of scheduled

launched_at DateTime time of spawn instance

terminated_at DateTime time of terminated

availability_zone String running zone name novadisplay_name String my first instance

display_description String Django + MySQL

launched_on Text first launched host info compute1

locked Boolean

os_type String Linux/Windows or others Linuxarchitecture String x86/i386

version of hypervisor. use for live migration. if source/dest hypervisor version is not same, fail to migration

cpu details info represented as json format

# '{"arch":"x86_64", # "model":"Nehalem", # "topology":{"sockets":1, "threads":2, "cores":3}, # "features":["tdtscp", "xtpr"]}'

NOSTATE = 0x00RUNNING = 0x01BLOCKED = 0x02PAUSED = 0x03SHUTDOWN = 0x04SHUTOFF = 0x05CRASHED = 0x06SUSPENDED = 0x07FAILED = 0x08BUILDING = 0x09

ACTIVE = 'active'BUILDING = 'building'REBUILDING = 'rebuilding'PAUSED = 'paused'SUSPENDED = 'suspended'RESCUED = 'rescued'DELETED = 'deleted'STOPPED = 'stopped'MIGRATING = 'migrating'RESIZING = 'resizing'ERROR = 'error'

SCHEDULING = 'scheduling'BLOCK_DEVICE_MAPPING = 'block_device_mapping'NETWORKING = 'networking'SPAWNING = 'spawning'IMAGE_SNAPSHOT = 'image_snapshot'IMAGE_BACKUP = 'image_backup'UPDATING_PASSWORD = 'updating_password'RESIZE_PREP = 'resize_prep'RESIZE_MIGRATING = 'resize_migrating'RESIZE_MIGRATED = 'resize_migrated'RESIZE_FINISH = 'resize_finish'RESIZE_REVERTING = 'resize_reverting'RESIZE_CONFIRMING = 'resize_confirming'RESIZE_VERIFY = 'resize_verify'REBUILDING = 'rebuilding'REBOOTING = 'rebooting'PAUSING = 'pausing'UNPAUSING = 'unpausing'SUSPENDING = 'suspending'RESUMING = 'resuming'RESCUING = 'rescuing'UNRESCUING = 'unrescuing'DELETING = 'deleting'STOPPING = 'stopping'STARTING = 'starting'

User editable field for display in user-facing UIs

User editable field for display in user-facing UIs

instance lock flag. When server.lock api called this flag turn on

vm_mode String pvhvhvm

uuid String universal unique id for live migration compute1-xxxxxxxx

root_device_name String device name for EBS boot /dev/sda

config_drive String values for vsa volume /dev/sdh

access_ip_v4 String ip for connect to the instance 64.142.4.112

access_ip_v6 String ip for connect to the instance 2001:0DB8:AC10:FE01

id Integer PK, Auto Increment

name String name of vsa vsa-xxxxxxxxdisplay_name String display in user-facing UIs My vsa

display_description String display in user-facing UIs used for database store

project_id String vsa owned project name dev project

availability_zone String vsa joined zone

instance_type_id Integer reference for InstanceTypes

image_ref String

vc_count Integer default 0

vol_count Integer defaut 0status String

InstanceActions id Integer PK

instance_id Integer FK Instance

action String action name for OSAPI extension add_tweedle

error Text error string

InstanceTypes id Integer PK

name String Uniquememory_mb Integer

vcpus Integer

local_gb Integer

flavorid Integer Unique

swap Integer Not Null, default 0 swap size associate with flavor

rxtx_quota Integer Not Null, default 0 It looks deprecate

rxtx_cap Integer Not Null, default 0 capacity of virtual network as mbps 100

Volume id Integer PK, Auto Incrementname String name of volume vol-xxxxxxxx

user_id String shida

project_id String dev_project

snapshot_id String snapshot id which volume's source snap-xxxxxxxx

host String host name of nova-volume localhost

size Integer size of volume by gb 2

availability_zone String availability zone name novainstance_id Integer volume attached instance id

mountpoint String device name of attached /dev/sdh

attach_time String time of attached

status String status of volume in-useavailablecreatingdeletingerrorerror_deleteing

attach_status String status of attach/dettach attacheddetached

scheduled_at DateTime

launched_at DateTimeterminated_at DateTime

display_name String

display_description String

provider_localtion String ISCSI provider location <ip>:<port>,<portal> <target IQN>

provider_auth String ISCSI provider authentication <auth method> <auth username> <auth password>

volume_type_id Integer reference for VolumeTypes

VolumeMetadata id Integer PKkey String meta data key

value String meta data value

volume_id Integer FK: Volume.volume_id

VolumeTypes id Integer PK

name String Unique

id Integer PK

key String extra spec keyvalue String extra spec value

volume_type_id Integer FK: VolumeTypes.id

Quota id Integer PK

project_id String Index quota for project

resource String type of quota

hard_limit Integer quota value

SnapShot id Integer PK

name String name of snapshot snap-xxxxxxxxvolume_name String name of source volume vol-xxxxxxxx

user_id String owned user id shida

project_id String owned project id dev project

volume_id Integer source volume id 1

status String snapshot status availableactivedeletingerror

progress String snapshot creation progress 1

volume_size Integer size of source volume 10display_name String

display_description String

id Integer PK, Auto Increment

instance_id Integer FK: Instance.id

device_name String device name /dev/sdb

delete_on_termination Boolean default false

snapshot_id Integer FK:Snapshots.id used for EBS bootingvolume_id Integer FK:Volume.id used for EBS booting

volume_size Integer size of volume

no_device Boolean flag of device exist or not

ExportDevice id Integer PK

shelf_id Integer composite key(blade_id)

blade_id Integer composite key(shelf_id)

volume_id Integer FK:Volumes.idIscsiTarget id Integer PK

target_num Integer iscsi target number

host String iscsi target host

volume_id Integer FK: Volumes.id

id Integer PK

security_group_id Integer FK: SecurityGroups.id

instance_id Integer FK:Instances.id

mode of vms. para virtualization or hardware virtualization

VirtualStorageArray

FK: Instances.id(Volume.deleted=false)

VolumeTypeExtraSpecs

BlockDeviceMapping

flag of deletion volume when instance terminated

SecurityGroupInstanceAssociation

SecurityGroups id Integer PKname String security group name

description String security group description

user_id String owned user id

project_id String owned project id

id Integer PK

parent_group_id Integer FK: SecurityGroups.id

protocol String tcp/udp/icmpfrom_port Integer acceptance port

to_port Integer acceptance port

cidr String CIDR 0.0.0.0

group_id Integer FK: SecurityGroups.id

id Integer PK

protocol String tcp/udp/icmp

from_port Integer acceptance portto_port Integer acceptance port

cidr String CIDR 0.0.0.0

KeyPair id Integer

name String keypair name

user_id String owned user

fingerprint String fingerprint

public_key Text RSA public keyMigration id Integer PK

source_compute String source host name shida

dest_compute String destination compute name shida2

dest_host String destination host name shida2

old_instance_type_id Integer reference for InstanceType

new_instance_type_id Integer reference for InstanceType

instance_uuid String FK:Instances.uuid

status String migration statusNetwork id Integer PK

label String network name used for iptables chain project1-net1

injected Boolean default false

cidr String Unique

cidr_v6 String Unique

multi_host Boolean default falsegateway_v6 String

netmask_v6 String

netmask String

bridge String

bridge_interface String

gateway String

broadcast String

dns1 String dns network definition when vps is on 192.168.0.1

dns2 String dns network definition when vps is on 192.168.0.1

vlan Integer

vpn_public_address String

vpn_public_port Integer

vpn_private_address String

dhcp_start String start address of dhcp 192.168.100.1project_id String associated project dev project

priority Integer network priority. append for Quantum

host String host name

uuid String

VirtualInterface id Integer PK

address String Unique

network_id Integer FK:Network.idinstance_id Integer FK:Instances.id

uuid String

fixed_ipv6 String

FixedIp id Integer PK

address String ip address

network_id Integer FK: Network.id

virtual_interface_id Integer FK:VirtualInterface.idinstance_id Integer FK:Instances.id

allocated Boolean default: false virtual interface is set

leased Boolean default: false dhcp bridge has leased the ip

reserved Boolean default: false


FloatingIp id Integer PK

address String ip address

fixed_ip_id Integer FK: FixedIp.idproject_id String associated project


auto_assigned Boolean default: false

AuthToken token_hash String PK

user_id String request's user shida

server_management_url String api server url http://localhost/services/Cloud

storage_url String Swift or other s3 service url https://cdn.swiftdrive.com/v1/CF_xer7_34

cdn_management_url String url of rackspace cdn https://cdn.swiftdrive.com/v1/CF_xer7_34

User id String PK shida

name String user name Takahiro Shida

access_key String user access key

secert_key String user secret key

is_admin Boolean flags for admin or notProject id String project id dev project

name String project fully qualified name Project for development

description String project description

project_manager String owner of this project shida

user_id String PK, FK:User.id shida

project_id String PK, FK:Project.id dev project

role String PK admin

SecurityGroupIngressRule

SecurityGroup we're granting access for

ProviderFirewallRule

flag to associate ip when instance started

UserProjectRoleAssociation

user_id String PK, FK:User.idrole String PK

user_id String PK, FK:User.id

project_id String PK, FK:Project.id

ConsolePool id Integer PK

address String console accessible address

username String

password Stringconsole_type String

public_host_name String

host String

compute_host String

Console id Integer PK

instance_name String name of instance

instance_id Integer reference for Instances.id

password String login passwordport Integer console opened port

pool_id Integer FK: ConsolePool.id

InstanceMetadata id Integer PK

key String metadata key

value String metadata value


id Integer PK

key String spec key

value String spec value


Zone id Integer PK

api_url String nova-api component's url

username String

password String

weight_offset Float default: 0.0 scheduling weight

weight_scale Float default: 1.0 scheduling weight

AgentBuild id Integer PK Xen Agent mechanizum

hypervisor String hypervisor name libvirt

os String instance os name Ubuntu

architecture String instance architecture type x86_64version String

url String

md5hash String

UserRoleAssociation

UserProjectAssociation

InstanceTypeExtraSpecs

user name of grant to access zone by using scheduler

user name of grant to access zone by using scheduler

University of Duisburg-Essen Paluno · 2013-12-16 · OpenStack: The Cloud OS echnicalT Report...

Documents

Transcript of University of Duisburg-Essen Paluno · 2013-12-16 · OpenStack: The Cloud OS echnicalT Report...