Bootstrapping A Simple Openstack Lab

In my last post, I waved my hands and assumed you had a deployment of Openstack to run the CoreOS cluster that was the subject of that post.  I felt a little absurd talking about autonomous, self-assembling infrastructure-in-a-box while choosing to forego a simple tutorial on setting up an all-in-one lab environment, at a minimum. So this time around, we’ll discuss a way you might bootstrap a simple Openstack deployment.  This setup will result in an RDO all-in-one Openstack system where the floating ip pool will be assigning valid IP addresses on your “public” network.  In this example, we pretend your lab subnet is  When you assign a floating IP address, any host that can route to that network will be able to talk to those floating IPs (assuming your security group allows it).

In my personal home lab, the first thing I set up was a Cobbler server.  I performed a minimal installation of CentOS 6.5 x86_64 with a netboot ISO, installed the EPEL repo, and set up Cobbler using the instructions on the Cobbler website.  I configured Cobbler to manage DHCP and DNS, and also installed cobbler-web.  I imported one distro: centos-6.5-x86_64.

Once installed and configured, I defined a system in cobbler for kickstart with PXE:

# cobbler system add --name=openstack --profile=centos-6.5-x86_64 --mac=FF:AA:BB:CC:DD:EE --ip-address= --gateway= --subnet= --static --hostname=openstack.home.lab --dns-name=openstack.home.lab --interface eth0

Assuming you have a suitable system whose mac address is FF:AA:BB:CC:DD:EE and is capable of PXE booting, the system will install using Cobbler’s default kickstart file.  [Read up on koan if you can’t PXE boot.  If all else fails, just do a minimal install off an ISO.]  You can define a kickstart file specific to this system, or modify the default kickstart file.  I created a new default kickstart file.  It looks something like:

# cat /var/lib/cobbler/kickstarts/homelab.ks
auth --useshadow --enablemd5
bootloader --location=mbr
clearpart --all --initlabel
firewall --enabled
firstboot --disable
keyboard us
lang en_US
url --url=$tree
rootpw --iscrypted $default_password_crypted
selinux --disabled
timezone America/New_York



echo "Installed: $(date)" > /etc/install_date

You’ll notice a couple of snippets that are homelab_xxx.  Those are the only custom snippets.  The home lab_ssh_keys just installs my ssh keys in the root authorized_keys file (hey, it’s a quick-and-dirty lab, right?).  The more interesting snippet is homelab_virt_setup:

yum install -y
yum -y install openstack-packstack
cat << EOF >
packstack --allinone --provision-all-in-one-ovs-bridge=n --os-heat-install=y --os-heat-cloudwatch-install=y --os-heat-cfn-install=y --neutron-lbaas-hosts=
chmod 755
wget http://cobbler.home.lab/

This leaves you with two scripts in /root/ on the new system after kickstart: and [NOTE: By the way, cobbler.home.lab is the fqdn of your cobbler server. Alternatively, you could substitute the server’s IP address. I placed into apache’s docroot (/var/www/html/ by default in CentOS).] The contents of


# Back up some files before overwriting ...
echo "backing up ..."
mkdir -p $BACKUP_DIR
cp /etc/sysconfig/network-scripts/ifcfg-br-ex $BACKUP_DIR/
cp /etc/sysconfig/network-scripts/ifcfg-eth0 $BACKUP_DIR/
cp /etc/neutron/plugin.ini $BACKUP_DIR/
echo "DONE"

# Set up the networking correctly ...
echo "Creating new br-ex ..."
cat << BREX > /etc/sysconfig/network-scripts/ifcfg-br-ex
echo "Done"
echo "Creating new eth0 ..."
cat << ETH0 > /etc/sysconfig/network-scripts/ifcfg-eth0
echo "Done"
echo "Editing plugin.ini ..."
sed -i '/^\[agent\]/ i \
network_vlan_ranges = physnet1 \
bridge_mappings = physnet1:br-ex' /etc/neutron/plugin.ini
echo "Done"

# Restart networking afterwards ...
/sbin/service network restart

# Finish neutron setup ...
echo "Tearing down old neutron config ..."
source /root/keystonerc_admin
neutron router-gateway-clear router1
neutron subnet-delete public_subnet
echo "Done"
echo "Creating new neutron config ..."
neutron subnet-create --name public_subnet --enable_dhcp=False --allocation-pool=start=,end= --gateway= public
neutron router-gateway-set router1 public
echo "Done"

I lifted these steps from a howto on the RDO website.  Again, note the specificity of the config (particularly with respect to network and interface names) and adjust it as necessary to your situation.  In this example, is the subnet of your lab network.  Floating IP addresses will be valid IPs on this network.

Once the system is kickstarted, you need to run (which takes about 20 minutes on my system) followed by a reboot, then (a split second) followed by a reboot. If you now log into this host, you will see a couple of keystonerc_xxx files.  These are the credentials to use when connecting to Openstack with the CLI tools.  You might do something like:

$ . keystonerc_demo
$ nova list

You’ll probably want to install the CLI tools on a workstation, but it would work to just SSH into the Openstack server to do everything.  You might also look at the horizon dashboard ( the web interface).  You can do almost everything from there, including importing template images to be used as the basis for all the future VMs you’ll create.  To carry out the CoreOS and Etcd exercise I wrote about, you’ll need to import an Openstack image from the official CoreOS channel and call it ‘coreos’.

The Openstack documentation is easy to read and constantly being updated.

Leave a Reply