starter-kit:compute (II) – Initial Setup

We’ll use Ubuntu LTS 14.04 (aka Trusty) as the base OS system installed in a dedicated computer (baremetal), but the same goals can be achieved using other distributions or using a virtual machine or container, but some requirements like networking and nested kvm needs to be changes.

In a first step, we will me using a single machine to run all the services (all-in-one) but we will expand this later in the series to include multiple compute nodes and include some HA features to accomplish our goal to have a real production environment.

Although more mainstream distributions include the OpenStack software packaged for them, we will be installing the services directly from source, using the latest available development version, so by the end of the series, we’ll be targeting the Liberty release. The rest of service needed by OpenStack will be installed using the distribution packaging system.

Necessary software

root@aio:~# apt-get install rabbitmq-server mysql-server git python-dev libmysqlclient-dev

In our case, we’ll call our node ‘aio’, but whatever you call your node, made sure that it resolves its hostname properly and to the address 127.0.0.1

And that’s all! Remember your mysql admin password for futures needs and we are ready to start the deployment of our first service: Keystone

Advertisement

The importance of caching

Having a great bandwidth connection is really useful when you need to retrieve different pieces from the Internet, but having a local mirror can really improve your build times.

As an example, building and deploying a full TripleO stack (seed, undercloud and overcloud vms) without any local mirrors and proxy takes (in my server) about 73 minutes, while using a local pypy mirror, apt mirror and a squid proxy takes only 41 minutes. That is roughly a 40% improvement! (Although a lot of this time is spent in booting and configuring the OpenStack vm’s ad services.

In a smaller case, just to build the seed vm (no vm ever booted), the times are the following:

1.- No cache/proxy = 12m 31s
2.- Squid proxy = 10.54
3.- Pypi mirror = 9m 56 s
4.- Pypi mirror + Squid Proxy = 8m 31 s
5.- Pypi mirror + Squid Proxy + Apt mirror = 6m 57s

Obviously, the worst your bandwidth if, the most time you will save!

You can also use the pypi mirror for other tasks, like updating your venv of your project for testing. Let’s take for example, ironic . Keeping in mind that the test suite takes ~ 25s, the times are:

– Without pypi mirror # tox -r -epy27 = 7m 58s
– With pypi mirror # tox -r -e epy27 = 7m 08s

So, hurray for local mirrors and proxys!


http://apt-mirror.github.io/
https://github.com/openstack-infra/pypi-mirror
http://www.squid-cache.org/
https://pypi.python.org/pypi/bandersnatch

pxe, e1000 and qemu-kvm 1.6 workaround

With the last update in Debian of qemu-kvm to version 1.6, booting vms via pxe with the e1000 (and ne2k_pci) network cards is no working anymore. I didn’t take a deep look of the issue yet, but there is an easy solution (actually 2) for that.

Easiest one:

wget https://github.com/qemu/qemu/raw/master/pc-bios/pxe-e1000.rom -O /usr/lib/ipxe/e1000_82540.rom

Another one:

git clone http://git.ipxe.org/ipxe.git 
cd ipxe/src 
make bin/8086100e.rom 
cp bin/8086100e.rom /usr/lib/ipxe/e1000_82540.rom

Long live to openvswitch-brcompat

Now that openvswitch-brcompat is not officially supported with recent kernels (Ubuntu 12.10 with kernel 3.5), the alternative to configure the bridges directly in the interfaces file has change a bit… but is still pretty forward!

Simple case with 1 bridge and 1 attached interface: 

allow-ovs br99

iface br99 inet dhcp
    ovs_type OVSBridge
    ovs_ports eth0
allow-br99 eth0
iface eth0 inet manual
    ovs_bridge br0
    ovs_type OVSPort

And to bring it up and down:

ifup --allow=ovs $list_of_bridges
ifdown --allow=ovs $list_of_bridges

Et voilà!

More info at: openvswitch-switch.README.Debian

Tip: Debugging tests in OpenStack

One easy way to debug tests in openstack using pdb, is to include the sentence:

import pdb; pbd.set_trace()

at the begining of the test is failing, and re-run it with the –nocapture option:

ghe@debian:glance(master)$ ./run_tests.sh -N glance.tests.functional.v1.test_api --nocapture
/home/ghe/github/openstack/glance/glance/tests/functional/v1/test_api.py(1170)test_delete_not_existing()
-> self.cleanup()
(Pdb) 


Happy sysadmin day!