Jump to: navigation, search

Smokestack

Revision as of 13:53, 30 August 2011 by Danprince (talk) (smokin' and drinkin' (holler!))

SmokeStack

A webUI to run smoke tests on the OpenStack.

Source Code

https://github.com/dprince/smokestack

Online at

http://smokestack.openstack.org/

Description

SmokeStack is a Rails application that provides a webUI and REST API to configure and smoke test the Openstack. It currently supports custom branches of Nova, Keystone, and Glance. Each test configuration allows you to customize the Nova, Keystone, and Glance branch and provides an option to merge w/ trunk (highly recommended). Each jobs builds its own Debian packages (using the PPA builder sources) which get installed via Chef on freshly built servers. The current set of functional/smoke tests include a set of Ruby openstack-compute bindings tests (for the v1.0 OSAPI), the Nova smoke tests (for the EC2 API), and Stacktester (for the v1.1 OSAPI).

SmokeStack is already proving to be quite useful as a tool to test Nova, Keystone, and Glance branches when they are in merge prop. It is also automated so that every single trunk commit fires a set of jobs to run tests against both Libvirt and XenServer 5.6 SP2 configurations.

webUI

Template:Http://c3323772.r72.cf0.rackcdn.com/main.png

Creating a new test configuration

SmokeStack currently supports custom Nova, Keystone, and Glance branches.

The following screenshot is the test configuration we currently run for every single trunk commit.

Template:Http://c3323772.r72.cf0.rackcdn.com/edit test trunk.png

A test config for a developer branch in merge prop might look something like this:

Template:Http://c3323772.r72.cf0.rackcdn.com/edit test adv.png

Advanced options are provided to specify custom:

  • Debian package builder URLs
  • Git Hash/Bzr revision: provide a way to test a previous revision of the source code.

Jobs

Each job goes into a Redis backed job queue. Smokestack currently has 5 job workers (which allows for 5 concurrent jobs to be running at any time). 3 workers run Libvirt configurations in the cloud and 2 workers use a hybrid cloud/bare metal server group to test XenServer. This is easily scalable by adding more workers, hardware, and Cloud Servers accounts.

Each job makes use of an openstack_vpc project template which is used to automate and control the setup of things in the cloud. The openstack_vpc project (available online here: https://github.com/dprince/openstack_vpc) is also a handy tool for developers who want to spin up groups of servers to have direct access to a fully working Openstack (Nova/Keystone/Glance) system in the cloud.

Here is what happens each time a job runs:

1) A Cloud Servers VPC group is created. (See https://github.com/rackspace/cloud_servers_vpc for more information)

2) Packages are built (in the cloud) based on the configured SmokeStack branches(Nova/Keystone/Glance). An API repo is created which is used to deploy these packages.

3) Chef is installed and each node configured according to the selected 'configuration' (see below).

4) Tests are executed (first the OSAPI tests, then the nova smoketests, then stacktester).

5) Results, logs, bzr/git revisions are harvested and stored in the SmokeStack DB.

The results look something like this:

Template:Http://c3323772.r72.cf0.rackcdn.com/job.png

Configurations

SmokeStack 'configurations' are groups of settings that define how each VPC group cloud is configured. Kind of like Amazon's "Cloud Formations" for functional testing. The following configuration options are available:

1) The type and size of Cloud Servers used to build the server group

2) The Chef cookbook repo used

3) The Chef roles and recipes that should be used for each node.

Template:Http://c3323772.r72.cf0.rackcdn.com/configuration.png

SmokeStack currently contains three configurations: Libvirt MySQL, Libvirt Postgres, and XenServer 5.6 SP2 w/ MySQL.

In the works

  • Lots of UI stuff (see the GitHub issues list)
  • Future configurations might support testing different nova configurations (zones), glance caching, larger groups of servers, etc.
  • Integrate with something like Dell's crowbar project to provide a clean/flexible UI for testing on bare metal.
  • Additional hypervisor support.