Many of us often times need to develop and test on OpenStack, however this becomes cumbersome as OpenStack releases new versions, where each needs to be installed and configured from scratch.
I found that a good solution is to install DevStack over a VirtualBox, but the challenge here is to overcome some OpenStack configuration and networking issues. By using this combination of Vagrant, VirtualBox, and DevStack, I found simple workarounds to easily install and work with OpenStack on a local environment.
The motivation was to be able to have a local development and testing environment for our entire dev team. Below is a tutorial for this DevStack Vagrant combination.
Let’s start with a vagrant file – which is the easiest way to configure the VM box.
You will need to download the right Linux distro and version number, I used Ubuntu 12.04. You will need to use the name you gave to the box (note that in the Gist I named in devstack5). You then need to provide an IP address for a private network. After you do so, you can allocate or create forwarding ports for all the OpenStack services’ API endpoints – Keystone, Neutron et al.
OpenStack automation – hack free. Cloudify – give it a roll. Go
Vagrant supports also configuration of the Vagrant VM that is brought up. You are able to configure its memory size, CPU, and other characteristics – for example look in the config VM provision section (towards the end of the file) where I created a machine 4 GB memory.
Next, you supply your own script, which I’ll elaborate on later, that describes the initial configuration of the box, when it is brought up.
After this, run vagrant up, and the box will then load.
SSH into the box to install DevStack. Reference Barak’s post for how to install DevStack.
Working with DevStack
DevStack comes with many configuration files, however, I’ve found that the simplest method is to change the localrc or the local.conf file to provide the information you need to configure DevStack.
In the localrc file you can provide passwords for your different services – RabbitMQ, Admin passwords, in addition to providing additional information you will need for the setup: floating IP ranges you’d like to use, the flat interface (e.g. ETH0), a location to store the log files, where the gateway is located, and services you‘d like to enable. For example, I enabled the Neutron service for networking purposes, (I’ll dive into networking hacks a bit later). In the Gists below you will also see how to access Devstack from the host machine, as well as how to access the instances launched inside DevStack from the outside world.
Cloudify natively integrates with OpenStack. Try it out. Go
After you create the configuration file, run stack.sh which will install MySQL and RabbitMQ, will compile and install all of the OpenStack components, and finally will bring the system up.
After the system is up and running you will be able to access it through the Horizon dashboard.
That’s the simple stuff. However, you will likely need to be able to have network access from the host machine to DevStack and to the launched instances. You’d be best off automating this as much as possible to simplify the process.
Kicking it Up a Notch
In the Vagrant file I defined a script that is being called to create networking routes, as well as allocate OpenStack resources and objects, and define security rules and more. This enables you to access DevStack from the host machine.
When I did this, I had a problem running it in one script, since I discovered that it has to run under a specific user. Since I installed DevStack under the “stack” user, I had to switch automatically from the vagrant user to the stack user before the script runs, as well as change the execution permissions to the file. To do so, I created a script called script.sh for the permission manipulation.
Through the start.sh file you can actually access external images, which you will need to do, since DevStack comes with a very small number of pre-loaded images that are not necessarily suitable, for example Ubuntu is not one of them. To do so, you can provide a URL or HTTP, and by using w-get you can download additional images. To bring DevStack up automatically, you’re also able to run the stack.sh from the script as well.
Note, that to add images it is not enough to download them and just put them in the directory, you will also need to tell Glance (the OpenStack image repository) to create a new image ID from the downloaded image.
Do this by calling glance image-create with the format, the container, and image reference.
Regarding networking, if you want to have DNS and name resolution the easiest way is to call the Neutron subnet update, and add a DNS name server. I added the Google public name server for name resolution – it’s IP address is 220.127.116.11.
Another networking configuration is to create security groups. I did this to be able to ping the new launched instances, and be able to SSH into them, as well as be able to access the web apps installed on port 80.
In order to be able to access the DevStack machine from the host machine, you have to use the route add command, as you can see in the example below. You will need to create a route using a gateway which tells the host machine if it receives a packet from a certain subnet to which interface it should be forwarded.
For this purpose I added two different routes. I did this before I ran the vagrant up command. In order to access the launch instances or ping them, you can use the name spaces.
I used the netns command to access the internal launched instances. OpenStack uses network namespaces to isolate networks where each virtual network gets its own space. A space means network interfaces, routing tables, IP tables separately for each tenant.
You can run IP netns list to receive the list of namespaces, and then choose the one you need.
Run exec with the namespace you defined, and define additional parameters such as IP tables, and routing information, for example:
sudo ip netns exec qrouter-1520casp2-f23c-497a-8578-3b2dcb7c2457 ping 10.0.0.7
sudo ip netns exec qrouter-152mnwd2-f54c-481a-8895-3b2dcb7c2624 ssh –i keyname email@example.com
I ran into a few issues when attempting to debug, so I chose to use the screens method explained in the DevStack + Heat post by Yoram. With the screen command you can see all of the DevStack terminals/consoles (about 15), e.g. Neutron, Nova, Horizon, APIs and others, and dive into their error messages.
To check that everything worked as it should, I launched a few instances, and was able to access them from the network.
Once I saw that it was up and running as needed, I packaged everything into a Vagrant box, this enables:
- Anyone to have their own DevStack local test and development environment.
- Anyone can have an IaaS in a box (VBox) locally – where you can define instances, configure, etc.
That’s it. With a few simple commands you can have your own local OpenStack and IaaS environments up and running.
If you want to upgrade to the newest OpenStack release follow the setup above, repackage it, and you’re good to go.