Page History
...
- marvin-nose - marvin plugin for nose
- should_dsl - should assertions dsl-style
Windows specifics
- For Windows (non-cygwin) development environment, following additional steps are needed to be able to install Marvin:
...
The developer profile compiles and packages Marvin. It does NOT install marvin Marvin your default PYTHONPATH.
As Marvin needs Cloudstack API's generated, a full build is needed before Marvin can be built.
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ mvn -P developer -DskipTests install
$ mvn -P developer -pl :cloud-marvin
|
Alternately, you can fetch marvin from jenkins as well: packages are built every hour here
Installation
| Code Block | ||||
|---|---|---|---|---|
| ||||
bash $ pip install tools/marvin/dist/Marvin-0.1.0*.tar.gz |
To upgrade an existing marvin installation and sync it with the latest APIs on the managemnet server, follow the steps here
First Things First
call this command
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ pip install --upgrade tools/marvin/dist/Marvin-*.tar.gz
|
First Things First
You will need a CloudStack management server that is already deployed, configured and You will need a CloudStack management server that is already deployed, configured and ready to accept API calls. You can pick any management server in your lab that has a few VMs running on it or you can use DevCloud or the simulator environment deployed for a checkin test #checkin. Create a sample json config file demo.cfg telling marvin where your management server and database server are.
The demo.cfg json config looks as shown below:
| Code Block | ||
|---|---|---|
| ||
json
{
"dbSvr": {
"dbSvr": "marvin.testlab.com",
"passwd": "cloud",
"db": "cloud",
"port": 3306,
"user": "cloud"
},
"logger": {
"LogFolderPath": "/tmp/"
},
"mgtSvr": [
{
"mgtSvrIp": "marvin.testlab.com",
"port": 8096,
"user": "root",
"passwd": "password",
"hypervisor": "XenServer",
}
]
}
|
...
- open up the integration.port on your management server as root user.
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ sudo iptables -I INPUT -p tcp --dport 8096 -j ACCEPT |
- Change the global setting integration.api.port on the CloudStack GUI to 8096 and restart the management server
...
Here is our test_deploy_vm.py modulemodule:
| Code Block |
|---|
python
#All tests inherit from cloudstackTestCase
from marvin.cloudstackTestCase import cloudstackTestCase
#Import Integration Libraries
#base - contains all resources as entities and defines create, delete, list operations on them
from marvin.integration.lib.base import Account, VirtualMachine, ServiceOffering
#utils - utility classes for common cleanup, external library wrappers etc
from marvin.integration.lib.utils import cleanup_resources
#common - commonly used methods for all tests are listed here
from marvin.integration.lib.common import get_zone, get_domain, get_template
class TestDeployVM(cloudstackTestCase):
"""Test deploy a VM into a user account
"""
@classmethod
def setUpsetUpClass(selfcls):
self.apiclient = selfsuper(TestDeployVM, cls)
def setUp(self):
self.apiclient = self.testClient.getApiClient()
self.testdata = self.testClient.getParsedTestDataConfig()
# Get Zone, Domain and Default Built-in template
self.domain = get_domain(self.apiclient, self.testdata)
self.zone = get_zone(self.apiclient, self.testClient.getZoneForTests())
self.testdata["mode"] = self.zone.networktype
self.template = get_template(self.apiclient, self.zone.id, self.testdata["ostype"])
#create a user account
self.account = Account.create(
self.apiclient,
self.testdata["account"],
domainid=self.domain.id
)
#create a service offering
self.small_service_offering = ServiceOffering.create(self.testdata["service_offerings"]["small"]
small_service_offering['storagetype'] self.apiclient,
= 'local'
self.testdata["service_offering"]["small"]
= ServiceOffering.create(
)
self.apiclient,
small_service_offering
)
#build cleanup list
self.cleanup = [
self.service_offering,
self.account
]
def test_deploy_vm
def tearDown(self):
"""Test Deploy Virtual Machine
try:
# Validate the following: cleanup_resources(self.apiclient, self.cleanup)
#except 1.Exception Virtualas Machinee:
is accessible via SSH
# 2. listVirtualMachines self.debug("Warning! Exception in tearDown: %s" % e)
def test_deploy_vm(self):
"""Test Deploy Virtual Machine
# Validate the following:
# - listVirtualMachines returns accurate information
"""
self.virtual_machine = VirtualMachine.create(
self.apiclient,
self.testdata["virtual_machine"],
accountid=self.account.name,
zoneid=self.zone.id,
domainid=self.account.domainid,
serviceofferingid=self.service_offering.id,
templateid=self.template.id
)
list_vms = VirtualMachine.list(self.apiclient, id=self.virtual_machine.id)
self.debug(
"Verify listVirtualMachines response for virtual machine: %s"\
% self.virtual_machine.id
)
self.assertEqual(
isinstance(list_vms, list),
True,
"List VM response was not a valid list"
)
self.assertNotEqual(
len(list_vms),
0,
"List VM response was empty"
)
vm = list_vms[0]
self.assertEqual(
vm.id,
self.virtual_machine.id,
"Virtual Machine ids do not match"
)
self.assertEqual(
vm.name,
self.virtual_machine.name,
"Virtual Machine names do not match"
)
self.assertEqual(
vm.state,
"Running",
msg="VM is not in Running state"
)
def tearDown(self):
try:
cleanup_resources(self.apiclient, self.cleanup)
except Exception as e:
self.debug("Warning! Exception in tearDown: %s" % e)
|
Parts of the test
imports
Parts of the test
imports
- cloudstackTestCase - All the cloudstack marvin cloudstackTestCase - All the cloudstack marvin tests inherit from this class. The class provides the tests with apiclient and dbclients using which calls can be made to the API server. dbclient is useful for verifying database values using SQL
- integration.lib.base - the base module contains all the resources one can manipulate in cloudstack. eg: VirtualMachine, Account, Zone, VPC, etc. Each resource defines a set of operations. For eg: VirtualMachine.deploy, VirtualMachine.destroy, VirtualMachine.list, etc. Each operation makes an API call: For eg: VirtualMachine.recover -> recoverVirtualMachineCmd returning a recoverVirtualMachineResponse. When dealing with the tests one only has to identify the set of resources one will be using and all the operations will autocomplete if you are using an IDE like PyDev/PyCharm
- integration.lib.utils - utility classes for performing verification/actions outside the API. Eg. ssh utilities, random_string generator, cleanup etc.
- integration.lib.common - simple methods that are commonly required for most of the tests, eg: a template -get_template, a zone-get_zone, etc
...
- You can also use the should_dsl to do asserts as it is included with the Marvin install and is more readable
Test Categories
Marvin supports test categories which enables you to run specific tests for product areas. For example if you have made a change in the accounts product area, there's a way to trigger all accounts related tests in both smoke and component tests directories. Just put a tag 'accounts' and point the directories/files
Example:
| Info |
|---|
nosetests --with-marvin --marvin-config=[config] --hypervisor=xenserver -a tags=accounts [file(s)] |
More info on this wiki page: Categories
Running the Running the test
IDE - Eclipse and PyDev
...
Note that the testclient is available from the superclass using getClsTestClient in this case.
| Anchor | ||||
|---|---|---|---|---|
|
Checkin/smoke Tests
The agent simulator and marvin are integrated into maven build phases to help you run basic tests before pushing a commit. These tests are integration tests that will test the CloudStack system as a whole. Management Server will be running during the tests with the Simulator Agent responding to hypervisor commands. For running the checkin tests, your developer environment needs to have Marvin installed and working with the latest CloudStack APIs. These tests are lightweight and should ensure that your commit doesnt break critical functionality for others working with the master branch. The checkin-tests utilize marvin and a one-time installation of marvin will be done so as to fetch all the related dependencies. Further updates to marvin can be done by using the sync mechanism described later in this section. In order for these tests to run on simulator, we need to add an attribute <required_hardware="false"> to these test cases.
These build steps are similar to the regular build, deploydb and run of the management server. Only some extra switches are required to run the tests and should be easy to recall and run anytime:
...
| Code Block |
|---|
$ sudo mvn -Pdeveloper,marvin.sync -Dendpoint=localhost -pl :cloud-marvin |
Run the Tests
Once the simulator is up, In a separate session you can use the following two commands to bring up n zone( below example creates an advanced zone with two simulator hypervisors followed by run tests that are tagged to work on the simulator:marvin.setup to bring up a zone with the config specified) and run tests.
command 1: Below command deploys a datacenter.
| Code Block |
|---|
$ mvn -Pdeveloper,marvin.setup -Dmarvin.config=python tools/marvin/marvin/deployDataCenter.py -i setup/dev/advanced.cfg |
Example configs are available in setup/dev/advanced.cfg
...
Example configs are available in and setup/dev/advancedbasic.cfg and
command 2: Below command runs the test.
| Code Block |
|---|
$ export MARVIN_CONFIG=setup/dev/ |
...
advanced.cfg |
...
marvin.test to run the checkin tests that are tagged to run on the simulator
...
$ export TEST_SUITE=test/integration/smoke
$ export ZONE_NAME=Sandbox-simulator
$ nosetests-2.7 \
--with-marvin \
--marvin-config=${MARVIN_CONFIG} \
-w ${TEST_SUITE} \
--with-xunit \
--xunit-file=/tmp/bvt_selfservice_cases.xml \
--zone=${ZONE_NAME} \
--hypervisor=simulator \
-a tags=advanced,required_hardware=false |
The --zone argument should match the name of the zone defined in the config file (currently Sandbox-simulator for basic.cfg and advanced.cfg).
Including your own
Check-In tests are the same as any other tests written using Marvin. The only additional step you need to do is ensure that your test is driven entirely by the API only. This makes it possible to run the test on a simulator. Once you have your test, you need to tag it to run on the simulator so the marvin test runner can pick it up during the checkin-test run. Then place your test module in the test/integration/smoke folder and it will become part of the checkin test run.
For eg:
| Code Block |
|---|
|
| Code Block |
|---|
@attr(tags =["simulatoradvanced", "advancedsmoke"], "smokerequired_hardware="false") def test_deploy_virtualmachine(self): """Tests deployment of VirtualMachine """ |
| Code Block |
|---|
|
The sample simulator configurations for advanced and basic zone is available in setup/dev/ directory. The default configuration setup/dev/advanced.cfg deploys an advanced zone with two simulator hypervisors in a single cluster in a single pod, two primary NFS storage pools and a secondary storage NFS store. If your test requires any extra hypervisors, storage pools, additional IP allocations, VLANs etc - you should adjust the configuration accordingly. Ensure that you have run all the checkin tests in the new configuration. For this you can directly edit the JSON file or generate a new configuration file. The setup/dev/advanced.cfg was generated as follows
...
Tests with more backend verification and complete integration of suites for network, snapshots, templates etc can be found in the test/integration/smoke and test/integration/component. Almost all of these test suites use common library wrappers written around the test framework to simplify writing tests. These libraries are part of the marvin.integrationlib package. Ensure that you have gone through the existing tests related to your feature before writing your own.
...
| Code Block |
|---|
tsp@cloud:~/cloudstack# nosetests --with-marvin --marvin-config=tools/devcloud/devcloud.cfg -a tags='devcloud' test/integration/smoke Test Deploy Virtual Machine ok Test Stop Virtual Machine ok Test Start Virtual Machine ok Test Reboot Virtual Machine ok Test destroy Virtual Machine ok Test recover Virtual Machine ok Test destroy(expunge) Virtual Machine ok ---- Ran 7 tests in 10.001s OK |
...
| Code Block |
|---|
import random
import marvin
from marvin.configGenerator import *
def describeResources():
zs = cloudstackConfiguration()
z = zone()
z.dns1 = '10.147.28.6'
z.internaldns1 = '10.147.28.6'
z.name = 'Sandbox-XenServer'
z.networktype = 'Advanced'
z.guestcidraddress = '10.1.1.0/24'
pn = physical_networkphysicalNetwork()
pn.name = "test-network"
pn.traffictypes = [traffictype("Guest"), traffictype("Management"), traffictype("Public")]
z.physical_networks.append(pn)
p = pod()
p.name = 'POD0'
p.gateway = '10.147.29.1'
p.startip = '10.147.29.150'
p.endip = '10.147.29.159'
p.netmask = '255.255.255.0'
v = iprange()
v.gateway = '10.147.31.1'
v.startip = '10.147.31.150'
v.endip = '10.147.31.159'
v.netmask = '255.255.255.0'
v.vlan = '31'
z.ipranges.append(v)
c = cluster()
c.clustername = 'C0'
c.hypervisor = 'XenServer'
c.clustertype = 'CloudManaged'
h = host()
h.username = 'root'
h.password = 'password'
h.url = 'http://10.147.29.58'
c.hosts.append(h)
ps = primaryStorage()
ps.name = 'PS0'
ps.url = 'nfs://10.147.28.6:/export/home/sandbox/primary'
c.primaryStorages.append(ps)
p.clusters.append(c)
z.pods.append(p)
secondary = secondaryStorage()
secondary.url = 'nfs://10.147.28.6:/export/home/sandbox/secondary'
z.secondaryStorages.append(secondary)
'''Add zone'''
zs.zones.append(z)
'''Add mgt server'''
mgt = managementServer()
mgt.mgtSvrIp = '10.147.29.111'
zs.mgtSvr.append(mgt)
'''Add a database'''
db = dbServer()
db.dbSvr = '10.147.29.111'
db.user = 'cloud'
db.passwd = 'cloud'
zs.dbSvr = db
'''Add some configuration'''
[zs.globalConfig.append(cfg) for cfg in getGlobalSettings()]
''''add loggers'''
testLogger = logger()
testLogger.logFolderPath = '/tmp/'
zs.logger = testLogger
return zs
def getGlobalSettings():
globals = { "storage.cleanup.interval" : "300",
"account.cleanup.interval" : "60",
}
for k, v in globals.iteritems():
cfg = configuration()
cfg.name = k
cfg.value = v
yield cfg
if __name__ == '__main__':
config = describeResources()
generate_setup_config(config, 'advanced_cloud.cfg')
|
...
| Code Block |
|---|
bash
$ nosetests --with-marvin --marvin-config=/path/to/basic_zone.cfg /path/to/tests
If we |
Attribute selection
The smoke tests and component tests contain attributes that can be used to filter the tests that you would like to run against your deployment. You would use nose attrib plugin for this. Following tags are available for filtering:
...
| Code Block |
|---|
bash $ nosetests --with-marvin --marvin-config=/path/to/config.cfg -w test<test_directorydirectory> -a tags=advanced # run tests tagged to run on an advanced zone with the simulator #Use below options to run all test cases under smoke directory on advanced zone "and" are provisioning cases, i.e., require hardware to run them. See "hypervisor" option to specify against which hypervisor to run them against, provided your zone and cluster has multiple hosts of various hypervisors type. $ nosetests-2.7 --with-marvin --marvin-config=/home/abc/softwares/cs_4_4_forward/setup/dev/advanced.cfg -w /home/abc/softwares/cs_4_4_forward/test/integration/smoke/ --with-xunit --xunit-file=/tmp/bvt_provision_cases.xml --zone=abc<zone_in_zonecfg> --hypervisor=<xenserver\kvm\vmware> -a tags=<advanced>advanced,required_hardware=<true>true #Use below options to run all test cases under smoke directory on advanced zone "and" are selfservice test cases, i.e., "not" requiring hardware to run them, and can be run against simulator. $ nosetests-2.7 --with-marvin --marvin-config=/home/abc/softwares/cs_4_4_forward/setup/dev/advanced.cfg -w /home/abc/softwares/cs_4_4_forward/test/integration/smoke/ --with-xunit --xunit-file=/tmp/bvt_provisionselfservice_cases.xml --zone=abc<zone_in_zonecfg> --hypervisor=<simulator>simulator -a tags=<advanced>advanced,required_hardware=<false>false #Use below options to run all test cases under smoke directory on advanced zone "and" are selfservice test cases, i.e., "not" requiring hardware to run them, and can be run against simulator. As well, below "deploy" option takes care to deploy datacenter as well. $ nosetests-2.7 --with-marvin --marvin-config=/home/abc/softwares/cs_4_4_forward/setup/dev/advanced.cfg -w /home/abc/softwares/cs_4_4_forward/test/integration/smoke/ --with-xunit --xunit-file=/tmp/bvt_provision_cases.xml --zone=abc<zone_in_zonecfg> --hypervisor=<simulator>simulator -a tags=<advanced>advanced,required_hardware=<false>false --deploy |
Guidelines to choose scenarios for integration
...
Overview
Content Tools
Apps