Let’s Build a Cloud — OpenStack

Joe Topjian, Systems Architect

This next part will familiarize yourself with some of the OpenStack components, how to build and install them, and how to use them. Although the rest of this series will focus on automating an OpenStack installation, it’s a good idea to know how to manually work with OpenStack before jumping in to automation.


Please see the Introduction to this series for a description of the required equipment needed to follow along.


Keystone is an identity management service for OpenStack. It provides management for users, groups, roles, and related permissions.

Since Keystone provides the authentication for OpenStack, it usually has to be the first OpenStack component to be set up.

Installing Keystone

To install Keystone, log in to the first server or virtual machine (hereafter known just as a server).

Next, download the latest stable Keystone and Keystone Client packages:

root@server:~# cd /usr/local/src
root@server:/usr/local/src# wget https://launchpad.net/keystone/essex/2012.1.1/+download/keystone-2012.1.1.tar.gz
root@server:/usr/local/src# wget https://launchpad.net/keystone/essex/2012.1/+download/python-keystoneclient-2012.1.tar.gz

The Keystone package is the actual Keystone OpenStack component. The Keystone Client package contains command-line utilities to interface with Keystone.

These packages were found on Keystone’s Launchpad page. Each OpenStack component has its own Launchpad page:

Next, decompress Keystone:

root@server:/usr/local/src# tar xzvf keystone-2012.1.1.tar.gz
root@server:/usr/local/src# cd keystone-2012.1.1

There is a tools directory inside the Keystone directory. tools contains a few different helper scripts. The first script of interest is pip-requires. This script will download all software packages that Keystone depends on. To run this script, and to install the other Keystone dependencies, do:

root@server:/usr/local/src/keystone-2012.1.1# apt-get install -y pip python-dev python-lxml
root@server:/usr/local/src/keystone-2012.1.1# pip install -r tools/pip-requires

Once the dependencies are satisfied, install Keystone:

root@server:/usr/local/src/keystone-2012.1.1# python setup.py install

Configuring Keystone

Keystone is now installed, but is not yet configured. To begin configuring Keystone, first create a directory to store Keystone’s config:

root@server:~# mkdir /etc/keystone

Next, copy the default configuration to this location:

root@server:~# cp /usr/local/src/keystone-2012.1.1/etc/* /etc/keystone/

This should have copied four files:

  • default_catalog.templates
    • This file describes how Keystone can interact with the other OpenStack components. In production, this data is usually stored in a database. For this exercise, this single file will work.
  • keystone.conf
    • This is the main Keystone config file. Settings in this file will be changed shortly.
  • logging.conf.sample
    • This file describes some examples on how Keystone can log.
  • policy.json
    • This file is for Keystone’s security policy settings.

With regard to keystone.conf, open this file in a text editor such as vi or nano:

root@server:~# cd /etc/keystone
root@server:/etc/keystone# vi keystone.conf

Make the following changes:

  • On Line 5, note the admin_token. You can leave it as-is or change it to something else.
  • On Line 20, change this line to:
    • connection = sqlite:////etc/keystone/keystone.db
  • On Line 38, change this line to:
    • template_file = /etc/keystone/default_catalog.templates

Once these changes are made, save the file and exit.

Now, launch Keystone. Since this exercise is just for testing purposes, Keystone will be launched on the command line without using an init script. Note that you will need to re-run this command if you reboot your server.

Open a new terminal or SSH session on the server, sudo to root, and type:

root@server:~# keystone-all

If all Keystone launched successfully, the last 3 lines will say:

DEBUG [keystone.common.wsgi] Starting /usr/local/bin/keystone-all on
DEBUG [eventlet.wsgi.server] (3922) wsgi starting up on
DEBUG [eventlet.wsgi.server] (3922) wsgi starting up on

In order to proceed, the Keystone Client tools need to be installed:

root@server:~# cd /usr/local/src
root@server:/usr/local/src# tar xzvf python-keystoneclient-2012.1.tar.gz
root@server:/usr/local/src# cd python-keystoneclient-2012.1
root@server:/usr/local/src/python-keystoneclient-2012.1# apt-get install -y python-prettytable
root@server:/usr/local/src/python-keystoneclient-2012.1# python setup.py install

Once this is done, ensure that /usr/local/bin/keystone exists — this is the primary tool used to interface with Keystone.

The first time that Keystone is launched, it needs a database created. To do this, run:

root@server:~# keystone-manage db_sync

Next, Keystone needs some initial data imported into the database. This data contains the base user, group, and role configuration. There is a script in the tools directory called sample_data.sh that contains this initial data.

root@server:~# cd /usr/local/src/keystone-2012.1.1/tools/

This script sets the default admin password to “secrete”. If you do not want this as your password, run the following command:

root@server:/usr/local/src/keystone-2012.1.1/tools# export ADMIN_PASSWORD=<YOUR ADMIN PASSWORD>

Now, run the file:

root@server:/usr/local/src/keystone-2012.1.1/tools# ./sample_data.sh

Finally, create a file called “openrc”. This file acts as a shortcut to specifying Keystone credentials so you do not have to type everything on the command line for each keystone command you run:

root@server:/root# cat > openrc <<EOF
export SERVICE_PASSWORD=password
export SERVICE_ENDPOINT=http://localhost:35357/v2.0
export OS_USERNAME=admin
export OS_AUTH_URL=http://localhost:35357/v2.0
export OS_TENANT_NAME=admin

Now you can do the following:

root@server:~# source /root/openrc
root@server:~# keystone tenant-list
root@server:~# keystone user-list
root@server:~# keystone service-list

If you are having problems with Keystone, check the session where you launched keystone-all. By default, Keystone does not log to a log file. Instead, everything is printed on the screen where you ran keystone-all.


Now that Keystone is up and running, other OpenStack components can be configured to use it for authentication and as a service catalogue. I’ll now demonstrate how Glance can be manually installed and how it can use Keystone.

Glance is OpenStack’s image catalogue service.

Installing Glance

A lot of these steps will be very similar to installing and configuring Keystone.

First, download the latest stable version of Glance:

root@server:~# cd /usr/local/src
root@server:/usr/local/src# wget https://launchpad.net/glance/essex/2012.1/+download/glance-2012.1.tar.gz

Decompress it:

root@server:/usr/local/src# tar xzvf glance-2012.1.tar.gz
root@server:/usr/local/src# cd glance-2012.1

Install it:

root@server:/usr/local/src/glance-2012.1# apt-get install -y python-iso8601 python-crypto
root@server:/usr/local/src/glance-2012.1# python setup.py install

Configuring Glance

Just like with Keystone, Glance will need to be manually configured:

root@server:~# mkdir /etc/glance
root@server:~# mkdir /var/log/glance
root@server:~# cp /usr/local/src/glance-2012.1/etc/* /etc/glance/
root@server:~# cd /etc/glance

There are two pairs of configuration files to edit. Each pair will have the same changes made.

The first pair is glance-api-paste.ini and glance-registry-paste.ini. At the end of these files, modify the final three lines to the appropriate credentials:

admin_tenant_name = admin
admin_user = admin
admin_password = <YOUR ADMIN PASSWORD>

The second pair is glance-api.conf and glance-registry.conf. At the end of these files, add the following two lines:

flavor = keystone

The above changes enable Glance to use Keystone as the authentication backend.

Finally, one last change. In glance-registry.conf, change Line 24 to read:

sql_connection = sqlite:////etc/glance/glance.sqlite

Next, open two new terminal or SSH sessions to the server and sudo to root for each one. In one of the sessions run:

root@server:~# glance-api

And in the other session run

root@server:~# glance-registry

If nothing has printed to the screen, then Glance is now running correctly. You can test Glance by doing:

root@server:~# source /root/openrc
root@server:~# glance index

There should be no output to this command — including no errors.

You can further test glance by importing a virtual machine image:

root@server:~# wget http://uec-images.ubuntu.com/releases/12.04/release/ubuntu-12.04-server-cloudimg-amd64-disk1.img
root@server:~# glance add name="Ubuntu 12.04 cloudimg amd64" is_public=true container_format=ovf disk_format=qcow2 < ubuntu-12.04-server-cloudimg-amd64-disk1.img

Now again run “glance index”. You should see the image that was just imported.

If you are having problems getting Glance to run, the log files for glance are stored in /var/log/glance.


This part of the series detailed how to install and configure two OpenStack components from scratch: Keystone and Glance. It also detailed how to configure Glance to use Keystone as the authentication backend.

This was done to help familiarize yourself with the basic patterns and characteristics of OpenStack components. Once these patterns are learned, you will be able to install other OpenStack components (Nova, for example) manually, but even more important, you will understand how these components work in a very detailed manner.

While this part of the series might have felt like an exercise in pain, if you followed through until the end and were able to get everything working correctly, you now have good edge on troubleshooting OpenStack; whereas if you used an automated installation solution right from the beginning, you would have no idea how any of the components actually worked.

If you would like to continue learning about OpenStack in this way, I suggest the following exercise:

Go back to a newly installed Ubuntu 12.04 installation (either by way of a clean install or reverting back to your virtual machine’s snapshot) and install Keystone, Glance and Nova by using the Ubuntu package repository. The steps will be quite similar to the above steps except that instead of downloading the OpenStack components via a tarball and wget, you will use apt-get. This document will give you a good head start.

You will know you have completed the exercise when you can run the command “nova image-list” and not have any errors returned.

Please note that this is a very difficult exercise. It will take patience, googling, and document reading.

Please enable JavaScript to view the comments powered by Disqus.
comments powered by Disqus