Page History

Tests running within devcloud worker VMs can ensure that the we can make basic tests in a continuous per-checkin fashionApache CloudStack's DevCloud appliance is used today to deploy a basic zone cloudstack environment. Within this devcloud appliance we run basic integration tests to ensure that essential functionality isn't broken by the rapid checkin process. This page lists the details on how these workers are setup with our continuous integration system.

Devcloud (Xenserver - basic)

The xcp-based devcloud is capable of deploying a basic zone cloudstack environment. We've patched this appliance with a clone of the incubator-cloudstack asf repo and our test utilities (marvin, cloudmonkey) and created a 'testcloud'  appliance. The following workflow explains the way tests are run within the appliance:

Workflow

The _testcloud _appliance contains an init script at /etc/init.d/devcloud that will start up a testrunner process when the appliance boots. Following this the testrunner will perform the necessary setup to prepare a basic zone cloudstack management server.

1. The test runner fetches the latest HEAD (currently set to master) from the git repository and builds cloudstack.  In other words - mvn install
2. This is followed by an installation of marvin so we have the latest APIs available via the test framework
3. Further on the management server jetty:run will start up a management server and have the API server listening for requests
4. We then configure this management server with the basic zone devcloud configuration with one XCP host and local storage. ie the config at tools/devcloud/devcloud.cfg
5. Once we have the basic zone running we will do a basic health check that verifies the following
   1. All system VMs have come up and are successfully 'Running'
   2. All the featured templates (built-in) are in Ready (downloaded) state
6. Iff the health check succeeds the environment is ready to run tests upon
7. nose's testrunner with the marvin plugin will collect all the tests marked with the 'attribute' of 'devcloud'  (@attr(tags='devcloud') , put them in a suite and run them
   1. The nose xUnit plugin gives us the XML out put for consumption into jenkins
8. Management Server log, logs from the test appliance's init script and the test results are posted to the machine hosting the 'testcloud' appliance
9. Jenkins slave agent will send through the results and logs to the jenkins master at jenkins.c.o

Test Workers

The host machine is a Ubuntu server with virtualbox 4.2 installed with guest additions. VirtualBox does dhcp for the 'testcloud' workers that it spins up. The testcloud image itself is cloned into multiple test workers (currently 5). A simple scheduler will pick up an idle worker vm on trigger from jenkins master that is polling for commits on the git:repo. Once picked up each worker will perform all the tests and post the results back to the gateway/dhcp which in our case is the host machine running virtualbox. A jenkins slave runs in headless mode on the host machine and posts results back to jenkins master.

After the testworker has done its job and posted its results back to jenkins we wait for a timeout (1800s) to release it back to the pool of workers. To clean up the image of any remnants from the previous test run the worker is restored to a base snapshot keeping the environment clean for the subsequent run.

Code
When we change mvn instructions for building cloudstack and /or the tests that need to run - the test runner process will fetch the latest version of itself from a github repo running devcloud-ci. This is useful so we don't change the image of the testcloud appliance when our build process changes.

All the code is hosted on github. Feel free to fork it, play around with it and contribute to making it an effective tool for automating our tests. Comments and Suggestions welcome on the cloudstack-dev@i.a.o lists

Devcloud (KVM - advanced)

WIP: We intend to do the same for a KVM based devcloud environment to so as to test any functionality that is essential for advanced zone CS deployments.