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 10.0.1.0/24.  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=10.0.1.253 --gateway=10.0.1.1 --subnet=255.255.255.0 --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
text
firewall --enabled
firstboot --disable
keyboard us
lang en_US
url --url=$tree
$yum_repo_stanza
$SNIPPET('network_config')
reboot
rootpw --iscrypted $default_password_crypted
selinux --disabled
skipx
timezone America/New_York
install
zerombr
autopart

%pre
$SNIPPET('log_ks_pre')
$SNIPPET('kickstart_start')
$SNIPPET('pre_install_network_config')
$SNIPPET('pre_anamon')
$SNIPPET('keep_ssh_host_keys')
%end

%packages
$SNIPPET('func_install_if_enabled')
$SNIPPET('package_list')
%end

%post
$SNIPPET('log_ks_post')
$yum_config_stanza
$SNIPPET('post_install_kernel_options')
$SNIPPET('homelab_ssh_keys')
$SNIPPET('homelab_virt_setup')
$SNIPPET('post_install_network_config')
$SNIPPET('func_register_if_enabled')
$SNIPPET('download_config_files')
$SNIPPET('koan_environment')
$SNIPPET('redhat_register')
$SNIPPET('cobbler_register')
$SNIPPET('post_anamon')
$SNIPPET('kickstart_done')
echo "Installed: $(date)" > /etc/install_date
%end

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 http://rdo.fedorapeople.org/rdo-release.rpm
yum -y install openstack-packstack
cat << EOF > install-packstack.sh
#!/bin/bash
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=10.0.1.253
EOF
chmod 755 install-packstack.sh
wget http://cobbler.home.lab/openstack-bridge-homelab-setup.sh

This leaves you with two scripts in /root/ on the new system after kickstart: packstack-install.sh and openstack-bridge-homelab-setup.sh. [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 openstack-bridge-homelab-setup.sh into apache’s docroot (/var/www/html/ by default in CentOS).] The contents of openstack-bridge-homelab-setup.sh:

#!/bin/bash

# Back up some files before overwriting ...
echo "backing up ..."
BACKUP_DIR="/root/backups"
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
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=10.0.1.253
NETMASK=255.255.255.0
GATEWAY=10.0.1.1
DNS1=10.0.1.254
DNS2=10.0.1.1
DNS3=8.8.8.8
ONBOOT=yes
BREX
echo "Done"
echo "Creating new eth0 ..."
cat << ETH0 > /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=F8:1A:67:03:56:67
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
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=10.0.1.50,end=10.0.1.99 --gateway=10.0.1.1 public 10.0.1.0/24
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, 10.0.1.0/24 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 packstack-install.sh (which takes about 20 minutes on my system) followed by a reboot, then openstack-bridge-homelab-setup.sh (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