This README describes the various tools available with Apache Cloudstack -

for compiling, deploying, building and testing the project

DevCloud

Under tools/devcloud

NOTE - DevCloud (tools/devcloud) is a work in progress. The project has not

determined how to best establish a nightly DevCloud build process, or how to

distribute the image.

Under tools/devcloud are various scripts used to build the devcloud image.

devcloudsetup.sh - the origional devcloud build script (assumes an Ubuntu 12.04

VM image)

$ cd tools/devcloud

* build_vagrant_basebox.sh - a script that uses VirtualBox, VeeWee, Vagrant

(patched) and puppet to create a devcloud basebox

* veewee - configuration files used to build a basic Ubuntu 12.04 vagrant box

via VeeWee

* basebuild - The Vagrantfile and puppet module that gets applied to the basic

Ubuntu 12.04 box

* devcloudbox - The Vagrantfile and puppet module that is used with the

[hopefully] distributed devcloud base box

To build a "devcloud base box", run you need a system with VirtualBox and rvm

installed (use ruby 1.9.2). Run build_vagrant_basebox.sh to build the base

box.

To use the "devcloud base box" that is created in the previous step, you need

to have installed a forked version of Vagrant (until we make the changes

plugins instead of direct source patches) that can be found here:

Once installed per the Vagrant installation process, run:

$ vagrant box add devcloud [path to devcloud.box]

Then, either go into the devcloudbox folder of your checked out version of the

CloudStack code (incubator-cloudstack/tools/devcloud/devcloudbox), or copy the

contents of that folder to another location.

Assuming the patched Vagrant installation is working, you then

simply run "vagrant up" from within that directory.

Install DevCloud Base system:

1. get code from https://github.com/jedi4ever/veewee, and install

2. veewee vbox define devcloud ubuntu-12.04-server-i386

3. put these two files(definition.rb and preseed.cfg) under ./definition/devcloud/

3. veewee vbox build devcloud

Marvin

Under tools/marvin

Marvin is the functional testing framework for CloudStack written in python.

Writing of unittests and functional tests with Marvin makes testing with

cloudstack easier

Visit the

[wiki](https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Python)

for the most updated information

$ untar Marvin-0.1.0.tar.gz

$ cd Marvin-0.1.0

$ python setup.py install

1. very handy cloudstack API python wrapper

2. support async job executing in parallel

3. remote ssh login/execute command

4. mysql query

Examples on how to develop your own configuration can be found in the marvin sandbox.

Under tools/marvin/marvin/sandbox

To generate the config for a deployment. Alter the .properties file in the sandbox. For example the

simualtordemo.properties after modification can generate the config file as

shown below

$ python simulator_setup.py -i simulatordemo.properties -o simulatordemo.cfg

To deploy the environment and run the tests

$ python -m marvin.deployAndRun -c simulatordemo.cfg -t /tmp/t.log -r /tmp/r.log -d testcase

Functional Tests written using marvin can be found under test/integration

folder. These are tests that are written to be run against a live deployed

system.

To run the tests - you should have marvin installed and correctly importable.

The tests are long running and are best monitored by external hudson jobs.

Also you will have to point marvin to the right configuration file that has

details about your cloudstack deployment. For more help on how to write the

config file and run tests check the tutorial at :

[] (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Python)

These test cases are the core functionality tests that ensure the application

is stable and can be tested thoroughly. These BVT cases definitions are

located at :

[] (https://docs.google.com/a/cloud.com/spreadsheet/ccc?key=0Ak8acbfxQG8ndEppOGZSLV9mUF9idjVkTkZkajhTZkE&invite=CPij0K0L)

BVT test cases are being developed using Python unittests2. Following are

certain guidelines being followed

1. Tests exercised for the same resource should ideally be present under a

single suite or file.

2. Time-consuming operations that create new cloud resources like server

creation, volume creation etc should not necessarily be exercised per unit

test. The resources can be shared by creating them at the class-level using

setUpClass and shared across all instances during a single run.

3. Certain tests pertaining to NAT, Firewall and Load Balancing warrant fresh

resources per test. Hence a call should be taken by the stakeholders regarding

sharing resources.

4. Ensure that the tearDown/tearDownClass functions clean up all the resources

created during the test run.

For more information about unittests: [] (http://docs.python.org/library/unittest.html)

Under test/integration/smoke

The following files contain these BVT cases:

1. test_vm_life_cycle.py - VM Life Cycle tests

2. test_volumes.py - Volumes related tests

3. test_snapshots.py - Snapshots related tests

4. test_disk_offerings.py - Disk Offerings related tests

5. test_service_offerings.py - Service Offerings related tests

6. test_hosts.py - Hosts and Clusters related tests

7. test_iso.py - ISO related tests

8. test_network.py - Network related tests

9. test_primary_storage.py - Primary storage related tests

10. test_secondary_storage.py - Secondary storage related tests

11. test_ssvm.py - SSVM & CPVM related tests

12. test_templates.py - Templates related tests

13. test_routers.py - Router related tests

Under test/integration/component

These test cases are the core functionality tests that ensure the application

is stable and can be tested thoroughly. These P1 cases definitions are located

at :

[] (https://docs.google.com/a/clogeny.com/spreadsheet/ccc?key=0Aq5M2ldK6eyedDJBa0EzM0RPNmdVNVZOWnFnOVJJcHc&hl=en_US)

The following files contain these P1 cases:

1. test_snapshots.py - Snapshots related tests

2. test_routers.py - Router related tests

3. test_usage.py - Usage realted tests

4. test_account.py - Account related tests

5. test_resource_limits.py - Resource limits tests

6. test_security_groups.py - Security groups related tests

7. test_templates.py - templates related tests

8. test_volumes.py - Volumes related tests

9. test_blocker_bugs.py - Blocker bugs tests

10. test_project_configs.py - Project global configuration related tests

11. test_project_limits.py - Project resource limits related tests

12. test_project_resources.py - Project resource creation related tests

13. test_project_usage.py - Project usage related tests

14. test_projects - Projects functionality tests

test/conf - EC2 script

To run submitCertEC2 and deleteCertEC2 scripts, update parameters in conf/tool.properties file:

* host - ip address of the host where cloud-bridge software is installed

* port - port cloud-bridge software is listening to

* accesspoint - access point for cloud-bridge REST request

* version - Amazon EC2 api version supported by cloud-bridge

* signaturemethod - HmacSHA1 or HmacSHA256

* expires - the date when certificate expires