Creating a home OpenStack lab with RDO and a couple spare laptops

Since part of my daily job is related to maintaining the Packstack codebase, I routinely run OpenStack installations every day… in a single VM, in my laptop, just to delete them a couple hours later. But sometimes I need to test some script or code over a live OpenStack installation, and I’d like to have a more stable environment to play with. Sure, there are public environments like TryStack, but I had a couple old laptops lying around, so why not play with them?

So the plan for today is to take these two laptops, install RDO on them, and have them be part of my home network, so that instances can connect to the Internet and get packages from the official repositories, and I can connect to them from my laptop using a floating IP in the same IP range as my home network.

The environment

My test environment is quite simple, I will create an OpenStack environment with one controller and one compute node. Both will be connected to my home network using a single network card.

• The controller node has a dual-core Intel Core2 Duo CPU, 4 GB of RAM, and two hard disks, each 160 GB.
• The compute node is more powerful, and it has a dual-core Intel i7-3520M CPU, 8 GB of RAM and a 320 GB hard disk.

Both systems have been set up with a minimal CentOS 7 installation with the latest updates.

Pre-installation tasks

Base OS pre-requisites

We need to get some operating system configuration on both the controller and compute nodes, before going on:

1. Make sure NTP is installed. It can be done during the CentOS installation, but if you forgot to do it, you can do so by running the following commands:

   # yum -y install chrony
   # systemctl enable chronyd
   # systemctl start chronyd

2. Disable NetworkManager. While this may not be needed anymore, I ran into some issues with my networking setup, so let’s go ahead and disable it for now:

   # systemctl disable NetworkManager
   # systemctl enable network
   # reboot

Set up RDO repositories

As a first step, let’s set up the RDO repository in the controller node. We will use Packstack to install our environment, and it will take care of enabling the required repos in the compute node.

# yum -y install https://www.rdoproject.org/repos/rdo-release.rpm
# yum -y update

This will setup the current RDO version (Liberty as of this writing). We run yum update after setting up the repository because there may be some packages in the RDO repo that override existing packages in CentOS. One such example is python-cffi, which will create issues if it is not up to date.

Create cinder-volumes volume group

The default Packstack setup uses LVM as a Cinder backend, which is enough for our lab purposes. However, it will create an LVM volume group called cinder-volumes on a loopback device if it is not there, so let’s use the second disk on the controller node for this.

# pvcreate /dev/sdb
# vgcreate cinder-volumes /dev/sdb

Installing

Create and edit the Packstack answer file

With all pre-requisites ready, we can install packstack and generate an answer file. We will not be using an all in one setup, instead we will create a custom answer file for our two-node environment

# yum -y install openstack-packstack
# packstack --gen-answer-file=answers.txt
# vim answers.txt

We will change the following variables from their default values:

CONFIG_HEAT_INSTALL=y
CONFIG_LBAAS_INSTALL=y
CONFIG_COMPUTE_HOSTS=192.168.1.186
...
CONFIG_NEUTRON_L3_EXT_BRIDGE=provider
CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,local,flat
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-enp8s0
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-enp8s0:enp8s0
CONFIG_PROVISION_DEMO=n

The first two options are self-explanatory: I decided to enable Heat and Neutron Load-Balancer-as-a-Service in my environment. You may want to enable other components, as Sahara or Trove.

About CONFIG_COMPUTE_HOSTS, Packstack will by default populate all host-related variables with the IP of the node it is running on. We want to use a different compute node, so that is why we need to change this variable.

The Neutron options deserve their own explanation, keep on reading.

Proper Neutron setup for the external network

This is where many non-trivial Packstack deployments have issues. Part of the problem is that the default all-in-one Packstack setup creates a simple, working Neutron setup, but one that does not allow you to connect to your external network easily:

• It creates an external network bridge br-ex.
• It creates a Neutron external network called public, associated to the external bridge, using a predefined floating IP range of 172.24.4.224/28, which probably will not match your home network.

So, with the settings specified above, we will do the following:

• We will instruct Packstack to set up Neutron to use provider networks, which look scary when reading about them but is basically the best way to define external networks.
• Packstack will create an OpenvSwitch bridge called br-enp8s0, associated to the controller’s network card called enp8s0 (it may be different in your setup), and associated to a Neutron flat network called physnet1.
• Packstack will not create any demo tenant, as we want to do that later.

This setup will require us to create the external network and tenant manually after the installation, but it will allow us to better understand what is going on.

Running the installation

This is now easy:

# packstack --answer-file=answers.txt

Packstack will ask you for the root password for all systems in your environment, and proceed with the installation. If something goes wrong, all log files will be located at /var/tmp/packstack/latest.

Hint: if you need to troubleshoot a failed environment, use the –debug command-line option. It will produce more more verbose logs

Post-installation steps

Now we need to create the Neutron external network that was not created before, as well as the tenant and user. Run the following commands on the controller node:

# . /root/keystonerc_admin
# neutron net-create public --provider:network_type flat 
  --provider:physical_network physnet1 --router:external
# neutron subnet-create --gateway 192.168.1.1 --allocation-pool  
  start=192.168.1.190,end=192.168.1.199 --disable-dhcp 
  --name public_subnet public 192.168.1.0/24

The above lines have created an external network called public, associated to the physnet1 network that we specified in the Packstack answer file (remember it was bound to an OpenvSwitch bridge connected to enp8s0), and a subnet for the floating IPs using your home network’s IP range, in this case 192.168.1.0/24. Note we are using a floating IP pool of 10 addresses, between 192.168.1.190 and 192.168.1.199, and it may be different in your case.

# openstack project create test
# openstack user create --project test --password-prompt --enable testuser

These lines create a test tenant, and a user called testuser in that tenant. The last command will prompt you for a password. Once that is done, you are ready to log on as your test user in the OpenStack dashboard:

Once you are there, you just need to define your tenant network, upload an image to Glance, and launch your first instance, which will then have access to your home network (and the Internet). Since this post is becoming too long, we will discuss this in a follow-up post.