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=188.8.131.52 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.