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�
1 Introduction to Cloud Computing 8
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.
1 Introduction to Cloud Computing 9
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
2 Introduction to OpenStack 11
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 Introduction to OpenStack 12
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.
2 Introduction to OpenStack 13
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
2 Introduction to OpenStack 14
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
2 Introduction to OpenStack 15
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.
2 Introduction to OpenStack 16
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]
3 Components of OpenStack 18
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.
3 Components of OpenStack 19
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 Components of OpenStack 20
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 Components of OpenStack 21
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
3 Components of OpenStack 22
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
3 Components of OpenStack 23
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
3 Components of OpenStack 24
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 Components of OpenStack 25
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 Components of OpenStack 26
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 Components of OpenStack 27
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.
3 Components of OpenStack 28
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
host String host name
FloatingIp id Integer PK
address String ip address
fixed_ip_id Integer FK: FixedIp.idproject_id String associated project
host String host name
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
instance_id Integer FK:Instances.id
id Integer PK
key String spec key
value String spec value
instance_id Integer FK:Instances.id
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