For developing and testing the F5 OpenStack agent and driver, I created a DevStack virtual machine on my MacBook Pro using VMware Fusion Pro for OSX version 7.1.3. DevStack is a collection of scripts that allows users to rapidly deploy an OpenStack environment. I run this DevStack virtual machine along with a BIG-IP Virtual Edition (VE) as a self-contained environment for quick development and test. If you would like to install this along with a BIG-IP Virtual Edition, I recommend reading Deploying F5 BIG-IP Virtual Edition on VMware Fusion by Chase Abbott. I will build upon his article and use the same networks so that the reader can integrate the BIG-IP into an OpenStack environment. In order to install both a DevStack VM and F5 BIG-IP Virtual Edition on the same host, I would recommend using a host with 16GB of RAM.
If you have followed the instructions on how to install and configure additional networking, you can use vmnet2 and vmnet4 as OpenStack public and API networks. If you do not wish to install VE and only need to set up VMware networks, then do the following:
Create Ubuntu 14.04 Instance
Download an ISO image Ubuntu Server 14.04.5 Trusty for the DevStack VM. There are more recent versions of Ubuntu available; however, these may not be supported by the OpenStack Mitaka release.
The VM that I create has 2 processor cores and 4GB RAM of -- it is not a very beefy setup, and more resources could be added, but this is good enough for a small development environment. If you want to add a BIG-IP VE on the same development host, you should stay within these constraints.
Provision Processors and Memory
Connect Network Adapters
Chose all the defaults during install until the network configuration.
Configure the Virtual DevStack VM
$ sudo apt-get update
$ sudo apt-get upgrade -y
$ sudo apt-get install git -y
Configure the VM networking
It is a good idea to create static IP addresses on the guest interfaces for the OpenStack service API endpoints. Edit the network configuration, /etc/network/interfaces. I modified mine based on the VM’s network adapter configuration.
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 10.128.1.128 netmask 255.255.255.0 gateway 10.128.1.2 auto eth1 iface eth1 inet static address 10.128.20.150 netmask 255.255.255.0 network 10.128.20.0
You must also update resolver configuration, /etc/resolvconf/resolv.conf.d/base
nameserver 220.127.116.11 search localdomain
Once you have finished, you can either restart networking and resolvconf or just reboot the guest.
These instructions are taken from the DevStack website:
Add Stack User
$ sudo adduser stack $ sudo echo “stack ALL=(ALL) NOPASSWD: ALL” >> /etc/sudoers
Login as the stack user or as the user you created when installing Ubuntu and clone the devstack repository. To work on Mitaka, checkout the stable mitaka branch.
$ git clone https://git.openstack.org/openstack-dev/devstack $ cd devstack $ git checkout –b stable/mitaka origin/stable/mitaka
Create a local.conf
The local.conf is used as configuration input to the DevStack deployment scripts. It is very configurable, but not well documented. Most of the default values in the configuration file are acceptable; however, if you want to explore the options available you will very likely find yourself delving into the deployment scripts. What I am providing is a sparse configuration to get Keystone, Glance, Nova, Neutron and Neutron-LBaaS running. The devstack repository contains a sample local.conf, devstack/samples/local.conf.
$ cp devstack/samples/local.conf devstack
# Neutron # ------- disable_service n-net enable_service neutron enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service q-lbaasv2 OVS_ENABLE_TUNNELING=True NEUTRON_CREATE_INITIAL_NETWORKS=False Q_USE_SECGROUP=True PUBLIC_INTERFACE=eth0 PUBLIC_BRIDGE=br-ex Q_USE_PROVIDERNET_FOR_PUBLIC=True OVS_PHYSICAL_BRIDGE=$PUBLIC_BRIDGE PHYSICAL_NETWORK=physnet PROVIDER_NETWORK_TYPE=flat
# Swift # ----- disable_service s-proxy disable_service s-object disable_service s-container disable_service s-account # Disable services disable_service horizon disable_service tempest # Fix for console issues on noVNC NOVNC_BRANCH=v0.6.0 # Make noVNC available on eth0 NOVNCPROXY_URL="http://10.128.1.128:6080/vnc_auto.html"
The swift project can be enabled, but I find it superfluous to manage object storage on a laptop virtual machine. The current version of Horizon exposes a bug in the openstack-sdk package that breaks the installation. It can be added back in on a subsequent build, but a change to the Mitaka requirements must be made first. I will add details below. The noVNC branch must be fixed at 0.6.0 or you will experience problems with console access to VM’s.
Now run the stack script. This will take about 15 minutes the first time to install, but once the service repositories are cloned will be much shorter on subsequent runs.
$ cd devstack $ ./stack.sh
Congratuations! You should now have a running Mitaka stack.
======================== DevStack Components Timed ======================== run_process - 46 secs test_with_retry - 3 secs apt-get-update - 6 secs pip_install - 238 secs restart_apache_server - 6 secs wait_for_service - 8 secs git_timed - 134 secs apt-get - 101 secs
Teardown and cleanup stack
Once you are finished with the deployment you should teardown the services and cleanup the stack.
$ cd devstack $ ./unstack.sh $ ./clean.sh
In order to get Horizon to work on the current stable mitaka branch, you will need to teardown your current stack and restack. Once the stack is cleaned up, edit the following file, /opt/stack/requirements/upper-constraints.txt by changing the upper constraint on openstacksdk. You can uncomment the disable_service horizon line in local.conf and then restack.
Change the line: