BasicBuildAutomationSpec


 * Launchpad Entry: Openstack-CI Basic Build Automation
 * Created: 2010-11-18
 * Contributors: JayPipes, JosephHeck

Summary
A basic build automation system is needed to fully test the wide array of configuration and deployment options for OpenStack projects.

Release Note
A basic build automation system has been created in the OpenStack-CI project. This automation system is used by the OpenStack project to do run a series of functional tests against real-world production deployment models. Read more about the OpenStack Continuous Integration project on Launchpad.

Rationale
The following are the goals of the build automation system:


 * Automation of Long-running Tests
 * Integration with Hudson Build System
 * Stress and Performance Testing of Real-world Deployments
 * Collection of Performance Metrics for Regression Analysis

User stories
Bob is a developer on the Nova project. He has added a spiffy new feature to Nova that allows a distributed datastore to be used instead of a centralised datastore. Before he proposes his branch for merging into trunk, Bob first would like to know if there are any functional or performance regressions from his new work. He runs the OpenStack-CI build automation system against his Launchpad branch, and he is emailed a report about the performance and functional regressions or improvements resulting from his branch.

Assumptions
None

Design
The build system will have a single program osci that performs a variety of commands, such as functional (for running functional tests) or stress (for running stress/performance tests).

In order to allow the most flexibility for testing a wide array of production deployment scenarios, we will create the concept of a *deployment configuration*. A deployment configuration will be a set of parameters that identify the hardware and host operating systems that osci will deploy OpenStack into and run its tests against. A deployment configuration will be represented by a JSON file that will be found in a directory defined by a program option called --deployment-config-dir.

A sample deployment configuration file might be:

{ "network": [{"host": "host2", "manager": "nova.network.manager.FlatNetworkManager"}], "host": [{"name": "host1", "address": "10.0.0.3"}, {"name": "host2", "address": "10.0.0.4"}], "api": [{"host": "host1", "api": "openstack"}], "scheduler": [{"host": "host1", "type": "simple"}], "messaging": {"broker": "rabbit", "address": "10.0.0.1:5672}, "datastore": {"engine_url": "mysql://username:password@10.0.0.2/nova"} }

The osci program will accept as it's first argument the name of a valid command. The second argument will always be a deployment configuration name. Subsequent arguments will be dependent on the command.

For example, if we saved the JSON file above to $ROOTDIR/config/deploy/basic.json, we could run the functional test suite in that deployment using the following:

$> osci functional basic

Implementation
In progress...