Part 2 – OpenStack installation and testing
After “Part 1 – Host environment preparation” you should have your CentOS v7, 64-bit instance up and running. This article will walk you through the OpenStack RDO installation and testing process.
Every command requires a Linux root privileges and is issued from the /root/ directory.
If you visited the RDO project website, you might have seen the Packstack quickstart installation instructions, recommending you issue a simple packstack --allinone command. Unfortunately, packstack --allinone does not build out OpenStack networking in a way that gives us external access to the guest machines. It doesn’t install the Heat project either. This is why we need to follow a bit more complex route.
Install and Set Up OpenStack RDO
- Install and update the RDO repos:
yum install -y https://repos.fedorapeople.org/repos/openstack/openstack-mitaka/rdo-release-mitaka-5.noarch.rpm yum update -y
- Install the OpenStack RDO Mitaka packages:
yum install -y centos-release-openstack-mitaka yum install -y openstack-packstack
I strongly recommend that you generate a Packstack answer file first, review it, and correct it if needed, then apply it. It’s less error-prone and it expedites the process of future re-installation (or later installation on a second host).
- Generate the Packstack answer file:
packstack --gen-answer-file=my_answer_file.txt \ --allinone --provision-demo=n --os-neutron-ovs-bridge-mappings=extnet:br-ex \ --os-neutron-ovs-bridge-interfaces=br-ex:ens33 --os-neutron-ml2-type-drivers=vxlan,flat \ --os-neutron-ml2-vni-ranges=100:900 --os-neutron-ml2-tenant-network-types=vxlan \ --os-heat-install=y \ --os-neutron-lbaas-install=y \ --default-password=default
NOTE: “ens33” should be replaced with the name of your non-loopback interface. Use “ip addr” to find it. You can remove the
--os-neutron-lbaas-install=y \line if you don’t intend to use your portable OpenStack cloud to play with F5 LbaaS as well. - Review the answer file (
my_answer_file.txt) and correct it if needed. - Apply the answer file (
my_answer_file.txt).
packstack --answer-file=my_answer_file.txtNow it’s time to take a long coffee or lunch break, because this part takes a while!
- Verify that a bridge has been properly created:
Your non-loopback interface should be assigned to an OVS bridge....
[root@mitaka network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-ens33 DEVICE=ens33 NAME=ens33 DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=br-ex ONBOOT=yes BOOTPROTO=none
.... and the new OVS bridge device should take over the IP settings:
[root@mitaka network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-br-ex DEFROUTE=yes UUID=015b449c-4df4-497a-93fd-64764e80b31c ONBOOT=yes IPADDR=10.128.10.3 PREFIX=24 GATEWAY=10.128.10.2 DEVICE=br-ex NAME=br-ex DEVICETYPE=ovs OVSBOOTPROTO=none TYPE=OVSBridge
- Change a virt type from qemu to kvm, otherwise F5 will not boot:
openstack-config --set /etc/nova/nova.conf libvirt virt_type kvm - Restart the nova compute service for your changes to take effect.
openstack-service restart openstack-nova-compute - Mitaka RDO may not take a default DNS forwarder from the
/etc/resolv.conffile, so you need to set it manually:openstack-config --set /etc/neutron/dhcp_agent.ini \ DEFAULT dnsmasq_dns_servers 10.128.10.2 openstack-service restart neutron-dhcp-agent
In this example, 10.128.10.2 is the closest DNS resolver; that should be your VMware workstation or home router (see part 1).
There are couple of CLI authentication methods in OpenStack (e.g. http://docs.openstack.org/developer/python-openstackclient/authentication.html). Let’s use the easiest – but not the most secure – one for the purpose of this exercise, which is setting bash environment variables with username, password, and tenant name.
The packstack command has created a flat file containing environment variables that logs you in as the admin user and the admin tenant. You can load those bash environment variables by issuing: source keystonerc_admin
Set Up OpenStack Networks
Next, we’ll configure our networks in OpenStack Neutron. The “openstack” commands will be issued on behalf of the admin user, until you load different environment variables. It’s a good time to review the keystonerc_admin file, because soon you will have to create such a file for a regular (non-admin) user.
- Load admin credentials:
source keystonerc_admin - Configure an external provider network:
neutron net-create external_network --provider:network_type flat \ --provider:physical_network extnet --router:external
- Configure an external provider subnet with an IP address allocation pool that will be used as OpenStack floating IP addresses:
neutron subnet-create --name public_subnet --enable_dhcp=False \ --allocation-pool=start=10.128.10.30,end=10.128.10.100 \ --gateway=10.128.10.2 external_network 10.128.10.0/24 \ --dns-nameserver=10.128.10.2
In the example given, 10.128.10.0/24 is my external subnet (the one configured during CentOS installation); 10.128.10.2 is both a default gateway and DNS resolver.
Please note that the OpenStack Floating IP address is a completely different concept than an F5 Floating IP address.
- F5 Floating IP address is an IP that floats between physical or virtual F5 entities in a cluster.
- OpenStack Floating IP address is a NAT address that is translated from a public IP address to a private (tenant) IP address. In this case, it is defined by
--allocation-pool=start=10.128.10.30,end=10.128.10.100
To avoid typos and confusion, let’s make further changes via the CLI and review the results in GUI.
In Chrome or Mozilla, enter the IP address you assigned to your CentOS host in your address bar:
http://<IP-address> (http://10.128.10.3, in my case).
NOTE: IE didn’t work with an OpenStack Horizon (GUI) Mitaka release on my laptop.
Set up a User, Project, and VM in OpenStack
Next, to make this exercise more realistic, let’s create a non-admin tenant, non-admin user, with non-admin privileges.
- Create a demo tenant (a.k.a. project):
openstack project create demo - Create a demo user and assign it to demo tenant:
openstack user create --project demo --password default demo - Create a keystone environment variable file for demo user that access demo tenant/project:
cp keystonerc_admin keystonerc_demo sed -i 's/admin/demo/g' keystonerc_demo source keystonerc_demo
Your bash prompt should now look like
[root@mitaka ~(keystone_demo)]#, since from now on all the commands will be executed on behalf of the demo user, within the demo tenant/project. In addition, you should be able to log into the OpenStack Horizon dashboard with the demo/default credentials. - Create a tenant router. Please double-check that your environment variables are set for demo user.
neutron router-create router1 neutron router-gateway-set router1 external_network
- Create a tenant (internal) management network:
neutron net-create management - Create a tenant (internal) management subnet and attach it to the router:
neutron subnet-create --name management_subnet management 10.0.1.0/24 neutron router-interface-add router1 management_subnet
Your network topology should be similar to that shown below (Network-> Network Topology-> Toggle labels):
- Create an ssh keypair, and store the private key to your pc. You will use this key for a password-less logging to all the guest machines:
openstack keypair create default > demo_default.pemStore demo_default.pem to your PC. Please remember to
chmod 600 demo_default.pembefore using it withssh -icommand. - Create an “allow all” security group:
openstack security group create allow_all openstack security group rule create --proto icmp \ --src-ip 0.0.0.0/0 --dst-port 0:255 allow_all openstack security group rule create --proto udp \ --src-ip 0.0.0.0/0 --dst-port 1:65535 allow_all openstack security group rule create --proto tcp \ --src-ip 0.0.0.0/0 --dst-port 1:65535 allow_all
Again, it’s not the best practice to use such a loose access roles, but the goal of this exercise is to create easy to use demo/test environment.
- Download and install a Cirros image (12.6MB):
curl http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img | \ openstack image create --container-format bare \ --disk-format qcow2 "Cirros image"
Check the image status:
+------------------+------------------------------------------------------+ | Field | Value | +------------------+------------------------------------------------------+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-08-29T19:08:58Z | | disk_format | qcow2 | | file | /v2/images/6811814b-9288-48cc-a15a-9496a14c1145/file | | id | 6811814b-9288-48cc-a15a-9496a14c1145 | | min_disk | 0 | | min_ram | 0 | | name | Cirros image | | owner | 65136fae365b4216837110178a7a3d66 | | protected | False | | schema | /v2/schemas/image | | size | 13287936 | | status | active | | tags | | | updated_at | 2016-08-29T19:12:46Z | | virtual_size | None | | visibility | private | +------------------+------------------------------------------------------+
- Spinning up your first Guest VM in your OpenStack environment. Here you will use previously created ssh key and allow_all security group. The guest image should be connected to the tenant “management” network.
openstack server create --image "Cirros image" --flavor m1.tiny \ --security-group allow_all --key-name default \ --nic net-id=management Cirros1
Now you should be able to access a Cirros1 console:
If everything went well, you should be able to log in to the Cirros1 VM with the cirros/subswin:) credentials and you should be able to ping www.f5.com from Cirros1. If your ping works, it looks like Cirros1 has got a way out.
Next, let’s create a way in, so we can ssh to the Cirros1 instance from outside.
If the console doesn’t react to keystrokes, click the blue bar with “Connected (unencrypted)” first. - Create an OpenStack floating IP address:
openstack ip floating create external_networkObserve a newly create IP address. You will use it in the next step:
+-------------+--------------------------------------+ | Field | Value | +-------------+--------------------------------------+ | fixed_ip | None | | id | 5dff365f-3cc8-4d61-8e7e-f964cef3bb8b | | instance_id | None | | ip | 10.128.10.31 | | pool | external_network | +-------------+--------------------------------------+
Now, the newly created “public” IP address may be attached to any Virtual Machine, Cirros1 in this case. Attaching an OpenStack floating IP address creates one-to-one network address translation between public IP address and tenant (private) IP address.
- Attach the OpenStack floating IP address to your Cirros1:
openstack ip floating add 10.128.10.31 Cirros1 - Test a way in: ssh from outside to your Cirros1:
ssh -i demo_default.pem cirros@10.128.10.31Or equivalent putty command. Check that you are really on Cirros1:
$id uid=1000(cirros) gid=1000(cirros) groups=1000(cirros)
If the test was successful, it looks like your basic OpenStack services are up and running. To spare a scarce CPU and memory resources, I’d strongly suggest to hibernate or remove Cirros1 VM.
Hibernating: openstack server suspend Cirros1 Removing: openstack server delete Cirros1
- Before you boot or shutdown the CentOS host, you should be aware of one CentOS/Mitaka specific issue: your hardware may be too slow to boot an httpd service within the default 90s. This is why I had to change this timeout:
sed -i \ 's/^#DefaultTimeoutStartSec=[[:digit:]]\+s/DefaultTimeoutStartSec=270s/g' \ /etc/systemd/system.conf
Useful troubleshooting commands: openstack-status, systemctl show httpd.service, systemctl status httpd.service.
In the next (and final) article in this series, we’ll install the F5 Heat plugins and onboard the F5 qcow2 image using F5 Heat templates.
