Chapter 2.

RDO Installation
We looked at the components that make up an OpenStack installation in the previous chapter;
let's now take a look at what's involved in installing and configuring these components. In
this chapter, we'll walk through the installation and configuration of a community-supported
distribution of OpenStack called RDO using an installation tool called Packstack.

Manual installation and configuration of OpenStack involves installing, configuring, and

registering each of the components we covered in the previous chapter and also multiple
databases and a messaging system. It's a very involved, repetitive, error-prone, and
sometimes-confusing process. Fortunately, there are a few distributions that include tools to
automate this installation and configuration process.

One such distribution is the RDO distribution. RDO, as a name, doesn't officially mean
anything. It's just the name of Red Hat's community-supported distribution of OpenStack.
Red Hat takes the upstream OpenStack code, packages its RPMs with several installation
options, and provides documentation, forums, IRC, and other resources for the RDO
community to use and support each other in running OpenStack on RPM-based systems.
There are no modifications to the upstream OpenStack code in the RDO distribution. The
RDO project packages the code that is in each of the upstream releases of OpenStack. This
means that we'll use an open source, community-supported distribution of vanilla OpenStack
for our example installation. RDO can be run on any RPM-based system, Fedora will be used
for the operating system, and Packstack will be used for the install tool for this demonstrative
installation. CentOS or other RPM Linux distributions should also work fine.

NOTE

Other installation options available with RDO include staypuft, a plugin for the foreman
and triple-o, which is short for OpenStack-on-OpenStack.

Installing RDO using Packstack

Packstack is an install tool for OpenStack intended for demonstration and proof of concept
deployments. The other two installation tools mentioned are intended for longer term
installations that need to be managed and maintained and are outside the scope of what we
will accomplish in this book. Packstack uses SSH to connect to each of the nodes and invokes
a puppet run (specifically a puppet apply) on each of the nodes to install and configure
OpenStack.

TIP

RDO website: http://openstack.redhat.com

RDO Quickstart: http://openstack.redhat.com/Quickstart

RDO Quickstart gives instructions to install RDO using Packstack in three simple steps:
 1. Update the system and install the RDO release rpm as follows:

2. sudo yum update -y

3. sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm

4. Install Packstack as shown in the following command:

5. sudo yum install -y openstack-packstack

6. Run Packstack as shown in the following command:

7. sudo packstack --allinone

TIP

Downloading the example code

You can download the example code files from your account at http://www.packtpub.com for
all the Packt Publishing books you have purchased. If you purchased this book elsewhere,
you can visit http://www.packtpub.com/support and register to have the flies e-mailed
directly to you.

The all in one installation method works well if you only have one server. It is a
recommended way to get OpenStack running quickly; that's exactly what Packstack is for—
building a deployment, tearing it down, and doing it again. In reality, however, a cluster will
usually need more than one compute node to host all the instances that end users will spawn.
Under the hood, the configuration of Neutron is slightly different for an all-in-one single-
server installation as compared to a multinode installation. So, instead of boxing our example
installation into a single server from the start as Quickstart does, we will work though a
multinode installation.

TIP

Don't avoid doing an all-in-one installation; it really is as simple as the steps make it out to
be, and there is value in getting an OpenStack installation done quickly. Getting an all-in-one
installation is something that can be done easily, and it will be more beneficial for us to cover
a multinode installation here.

The environment we will work through here will be useful in Chapter 11, Scaling
Horizontally, to demonstrate adding compute nodes to OpenStack when scaling is covered.
Packstack can do this multinode installation; it will just take additional configuration to pass
to Packstack before the installation starts.

TIP

Compute nodes are the hypervisor nodes where the instances run. Neutron is the networking
component.
Preparing nodes for installation

Before working on the extra configuration, let's define the architecture for our demonstration
cloud. Let's use three nodes, one for each of our logical categories of OpenStack that were
defined earlier:

 A control node
 A network node
 A compute node
Each node will have two network interfaces. The eth0 interface on each node will be in
the 192.168.123.0/24 subnet, and the eth1 interface will be in the 192.168.122.0/24 subnet.
We will assign IPs as shown in the following two paragraphs.
The 192.168.122.0/24 subnet represents the public network that the nodes are connected to,
and the 192.168.123.0/24 subnet represents the private network. These networks represent
the physical network that will carry communication in and out of the OpenStack cluster. In
reality, more than two networks should exist. A recommended architecture still has the
internal or data network for communication within OpenStack. The networking traffic for the
instances and the storage traffic would also have their own segregated networks requiring
four interfaces on each node for a more complete deployment. Our example will only use two
networks to simplify the installation.
Make sure that your nodes have several CPUs and a minimum of 4 to 6 GB of RAM, and
install CentOS or Fedora or another RPM-based Linux distribution of your choice. This will
allow you to install OpenStack and launch a few small instances. If you're running low on
resources, you could merge the control and network nodes into one node and initially run a
two-node cluster.

Installing Packstack and generating an answer file

Now that we have an architecture defined for installation, let's take a look at the extra
configuration that will be passed into Packstack using an answer file. The Packstack
command has a parameter that can be passed to generate an initial answer file for you. This
file is simply a text file full of key-value pairs that are initially generated with all the default
values used for the all-in-one installation. The all-in-one installation actually generates the
same file and uses it to complete the installation. To get started, log in to your control node.
Set up the RDO repository, install Packstack, and generate a new answer file as follows:

mylaptop$ ssh root@192.168.122.101

control# yum update -y

control# yum install -y http://rdo.fedorapeople.org/rdo-release.rpm

control# packstack --gen-answer-file myanswers.txt

When you edit the generated file, you'll see an extensive list of key-value pairs that configure
all the different OpenStack components.
Now that you have a Packstack file generated, let's start walking through customizing it. The
first thing to notice is that Packstack has filled in all the HOST configuration options with an IP
address. If the 192.168.123.101 address was not used, search and replace all of these values
to ensure that the 123 network will be used. Here's the command to accomplish this:

control# sed -i 's/192.168.122.101/192.168.123.101/g' myanswers.txt

Next, we will update some of the sample host values to reflect the architecture just mapped
out. Set the Neutron HOST values to the Neutron host IP address and the compute HOST value
to the computer host. Also, update the Horizon HOST value to use the public IP of the host.
This ensures that things get configured properly to expose the web interface on the public
network. Here's how we accomplish this:

CONFIG_NEUTRON_SERVER_HOST=192.168.123.102

CONFIG_NEUTRON_L3_HOSTS=192.168.123.102

CONFIG_NEUTRON_DHCP_HOSTS=192.168.123.102

CONFIG_NEUTRON_METADATA_HOSTS=192.168.123.102

CONFIG_NOVA_COMPUTE_HOSTS=192.168.123.103

CONFIG_HORIZON_HOST=192.168.122.101

For networking to work properly in a multinode configuration, there are extra

configuration options needed. We'll use Virtual Extensible LAN (VXLAN) tunneling.
Update these configuration options to specify the VXLAN configuration:

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=vxlan

CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:1000

CONFIG_NEUTRON_OVS_TUNNEL_IF=eth0

Finally, two of the components we'll cover are not installed by default in Packstack, so we
will enable these as follows:

CONFIG_SWIFT_INSTALL=y

CONFIG_HEAT_INSTALL=y

Now that the extra hosts are configured, the extra components are added, and the networking
configuration is updated, this file needs to be fed into Packstack to execute the installation.
Packstack is invoked using the --answer-file parameter with the answer file as the argument
value; here's how:

control# packstack --answer-file myanswers.txt

It's important to note here that when Packstack is run with this option, it is an idempotent run.
So, if something fails in the Packstack run, you can correct it and rerun Packstack. All the
other ways of invoking Packstack, all-in-one included, are not idempotent; only --answer-
file is. This is very important because when a new answer file is generated, all new
passwords get generated too. Consequently, if a previous Packstack run set up something that
used one of the generated passwords, then using a newly generated answer file with new
passwords will never succeed.
Let's look at how a successful Packstack run will look. When you execute Packstack and pass
the answer file, the first section will ensure connectivity to the nodes and then generate
manifest entries. There are a large number of lines in the output referring to these manifest
entries, so the output here has been truncated. Where you see {XYZ} in this output, you can
assume that you'll see the line repeated for all the different items that need manifests for
installation. Manifest entries are files that are full of puppet classes. The manifest files are
configuration definitions that will invoke puppet modules on the nodes when the puppet is
run on them.
Next in this output, you will see pairs of lines that read Applying
{IP_ADDRESS}_{XYZ}.pp and {IP_ADDRESS}_{XYZ}.pp [DONE]. Each of the IP addresses in the
answer file will be associated with the different items that need to be installed and configured
for the OpenStack installation. When each of these tasks gets started, an Applying message is
printed, and when each finishes, a [DONE] message is printed. Finally, if everything went
successfully, a success message will be provided with any information important to the
completed installation. Here's the output summary:

control# packstack --answer-file myanswers.txt

Welcome to Installer setup utility

Packstack changed given value y to required value n

Installing:

Clean Up [ DONE ]

Setting up ssh keys [ DONE ]

Discovering hosts' details [ DONE ]

Adding {XYZ} manifest entries [ DONE ]

Preparing servers [ DONE ]

Installing Dependencies [ DONE ]

Copying Puppet modules and manifests [ DONE ]

Applying 192.168.123.103_{XYZ}.pp

Applying 192.168.123.101_{XYZ}.pp

Applying 192.168.123.102_{XYZ}.pp

Applying 192.168.122.101_{XYZ}.pp

192.168.123.102_{XYZ}.pp: [ DONE ]

192.168.123.103_{XYZ}.pp: [ DONE ]

192.168.123.101_{XYZ}.pp: [ DONE ]

192.168.122.101_{XYZ}.pp: [ DONE ]

Applying Puppet manifests [ DONE ]

Finalizing [ DONE ]

**** Installation completed successfully ******

Additional information:

* Time synchronization installation was skipped. Please note that unsynchronized

time on server instances might be problem for some OpenStack components.

* Did not create a cinder volume group, one already existed

* File /root/keystonerc_admin has been created on OpenStack client host

192.168.123.101. To use the command line tools you need to source the file.
 * To access the OpenStack Dashboard browse to http://192.168.122.101/dashboard .

Please, find your login credentials stored in the keystonerc_admin in your home
directory.

* To use Nagios, browse to http://192.168.123.101/nagios username : nagiosadmin,

password : 918aa228abe04e6d

* Because of the kernel update the host 192.168.123.103 requires reboot.

* Because of the kernel update the host 192.168.123.101 requires reboot.

* Because of the kernel update the host 192.168.123.102 requires reboot.

* Because of the kernel update the host 192.168.122.101 requires reboot.

* The installation log file is available at: /var/tmp/packstack/20140528-003206-

reQmjV/openstack-setup.log

* The generated manifests are available at: /var/tmp/packstack/20140528-003206-

reQmjV/manifests

This installation run required a reboot of the nodes because of a kernel update. If this is
indicated, make sure to do the reboot. In some cases, you may have got a new kernel that has
added support for network namespaces required by the advanced networking.

As part of the Packstack run, a file named keystonerc_admin is created on the control node
with the administrative user's credentials. Cat this file to see its contents and get credentials to
log in, as follows:

control# cat ~/keystonerc_admin

export OS_USERNAME=admin

export OS_TENANT_NAME=admin

export OS_PASSWORD=1ef82c52e0bd46d5

export OS_AUTH_URL=http://192.168.123.101:5000/v2.0/

export PS1='[\u@\h \W(keystone_admin)]\$ '

Now that you have an OpenStack installation and the credentials to log in, open your web
browser and go to the IP address you used for your CONFIG_HORIZON_HOST configuration
parameter. The demonstration installation configuration values would expose the web server
as shown in the following screenshot of the page at http://192.168.122.101/.
Use the admin user and the generated password that came from the keystonerc_admin file to
log in. If all went properly, you would be presented with the OpenStack dashboard web
interface. Here's a screenshot of the hypervisor list showing the single hypervisor in the
cluster built in this chapter:
Packstack: Create a proof of concept cloud
This document shows how to spin up a proof of concept cloud on one node, using the Packstack installation utility. You will be able to add more nodes to your OpenStack cloud later, if you
choose.

The instructions apply to the current Ocata release.

Summary for the impatient

If you are using non-English locale make sure your /etc/environment is populated:

LANG=en_US.utf‐8
LC_ALL=en_US.utf‐8

If your system meets all the prerequisites mentioned below, proceed with running the following commands.

On RHEL:

$ sudo yum install ‐y https://www.rdoproject.org/repos/rdo‐release.rpm

$ sudo yum update ‐y
$ sudo yum install ‐y openstack‐packstack
$ sudo packstack ‐‐allinone

On CentOS:

$ sudo yum install ‐y centos‐release‐openstack‐ocata

$ sudo yum update ‐y
$ sudo yum install ‐y openstack‐packstack
$ sudo packstack ‐‐allinone

Step 0: Prerequisites
Software
Red Hat Enterprise Linux (RHEL) 7 is the minimum recommended version, or the equivalent version of one of the RHEL-based Linux distributions such as CentOS, Scientific Linux, and so on.
x86_64 is currently the only supported architecture.

See RDO repositories for details on required repositories.

Name the host with a fully qualified domain name rather than a short-form name to avoid DNS issues with Packstack.

Hardware
Machine with at least 4GB RAM, preferably 6GB RAM, processors with hardware virtualization extensions, and at least one network adapter.

Network
If you plan on having external network access to the server and instances, this is a good moment to properly configure your network settings. A static IP address to your network card, and
disabling NetworkManager are good ideas.

$ sudo systemctl disable firewalld

$ sudo systemctl stop firewalld
$ sudo systemctl disable NetworkManager
$ sudo systemctl stop NetworkManager
$ sudo systemctl enable network
$ sudo systemctl start network

If you are planning on something fancier, read the document on advanced networking before proceeding.

Step 1: Software repositories

On RHEL, download and install the RDO repository RPM to set up the OpenStack repository:

$ sudo yum install ‐y https://rdoproject.org/repos/rdo‐release.rpm

On CentOS, the Extras repository provides the RPM that enables the OpenStack repository. Extras is enabled by default on CentOS 7, so you can simply install the RPM to set up the
OpenStack repository:

$ sudo yum install ‐y centos‐release‐openstack‐ocata

Update your current packages:

$ sudo yum update ‐y

Looking for an older version? See http://rdoproject.org/repos/ for the full listing.

Step 2: Install Packstack Installer

$ sudo yum install ‐y openstack‐packstack

Step 3: Run Packstack to install OpenStack

Packstack takes the work out of manually setting up OpenStack. For a single node OpenStack deployment, run the following command:

$ sudo packstack ‐‐allinone

If you encounter failures, see the Workarounds page for tips.

If you have run Packstack previously, there will be a file in your home directory named something like packstack‐answers‐20130722‐153728.txt You will probably want to use that file again,
using the ‐‐answer‐file option, so that any passwords you have already set (for example, mysql) will be reused.

The installer will ask you to enter the root password for each host node you are installing on the network, to enable remote configuration of the host so it can remotely configure each node
using Puppet.

Once the process is complete, you can log in to the OpenStack web interface Horizon by going to http://$YOURIP/dashboard . The user name is admin . The password can be found in the file
keystonerc_admin in the /root directory of the control node.

Next steps
Now that your single node OpenStack instance is up and running, you can read on about running an instance, configuring a floating IP range, configuring RDO to work with your existing
network, or about expanding your installation by adding a compute node.

DOCS USE RDO COMMUNITY SUPPORT

Download Packstack Participate Red Hat OpenStack Platform
Common questions TripleO Quickstart Ask (Q&A) Contact us
Troubleshooting Releases Browse open issues
About RDO Trunk builds Report a problem

© 2017 RDO Legal & Privacy Edit this page on GitHub RDO is a Red Hat-sponsored community project