DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Apache CloudStack's DevCloud appliance is used today to deploy a basic zone cloudstack CloudStack environment. Within this devcloud 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.
| Table of Contents |
|---|
...
The xcpXCP-based devcloud DevCloud is capable of deploying a basic zone cloudstack CloudStack environment. We've patched this appliance with a clone of the incubator-cloudstack 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:
...
The testcloud appliance contains an init script at /etc/init.d/devcloudDevCloud 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 CloudStack management server.
| Wiki Markup |
|---|
[nose|https://nose.readthedocs.org/en/latest/]'s testrunner with the marvin plugin will collect all the tests marked with the '_attribute'_ of '_devcloudDevCloud' \[@attr(tags='devcloudDevCloud')\] ,_ put them in a suite and run them |
...
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.
...
Code
When we change mvn instructions for building cloudstack 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 devcloudDevCloud-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 cloudstackCloudStack-dev@i.a.o lists
The jenkins job is a vanilla job enabled with junit reports. Email will be enabled to cloudstackCloudStack-commits@i.a.o
The setup is a single machine with 4 core CPU, 8GB RAM and 500GB of hard disk space. Installed with Ubuntu 12.04 LTS - Server Edition.
...
3. wget the testcloud appliance to your server. The appliance is pre-seeded with the init script that will launch the test runner and configure cloudstackCloudStack. import the appliance into virtualbox to change the default credentials in the script to suit those of your jenkins user.
...
4. start the vm and login to devcloudDevCloud
| Code Block |
|---|
$ vboxmanage startvm testcloud --type headless |
and change the password in the /etc/init.d/devcloud DevCloud init script
| Code Block |
|---|
28 python28 python $SCRIPTDIR/setUpTestWorker.py --host 192.168.56.1 --user jenkins --pass yourpassword --out /var/lib/jenkins/reports |
and then reinitialize the system-V service
| Code Block |
|---|
$ update-rc.d devcloudDevCloud defaults |
5. stop the vm and export it as an appliance out of which we will create further test workers.
...
3. Draft a proposal for moving this to builds.a.o
...
WIP: We intend to do the same for a KVM based devcloud DevCloud environment to so as to test any functionality that is essential for advanced zone CS deployments.