Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: no reason to cut this line

...

The developer profile compiles and packages Marvin. It does NOT install marvin your default PYTHONPATH.

Code Block
languagebash
titlebuilding marvin
bash
$ mvn -P developer -pl :cloud-marvin

Alternately, you can fetch marvin from jenkins as well: packages are built every hour here

Installation

Code Block
languagebash
titlefresh install of marvin

$ pip install tools/marvin/dist/Marvin-*.tar.gz

To upgrade an existing marvin installation and sync it with the latest APIs on the managemnet server, call this command

...

Code Block
languagebash
titleupgrade of an existing marvin installation from source
 $ 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 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
titlean example environment definition
#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
languagebash
titleopen access to your management server
$ 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

...

  • 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 test

IDE - Eclipse and PyDev

...

Code Block
$ python tools/marvin/marvin/deployDataCenter.py \
    -i setup/dev/advanced.cfg

Example configs are available in setup/dev/advanced.cfg and setup/dev/basic.cfg

...


command 2: Below command runs the test.

...

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 =["advanced", "smoke"],required_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

...