virtualenv venv
source venv/bin/activate

git clone https://github.com/cloudify-cosmo/cloudify-cli.git
pip install -e cloudify-cli -r cloudify-cli/dev-requirements.txt

git clone https://github.com/cloudify-cosmo/cloudify-system-tests.git
pip install -e cloudify-system-tests

git clone https://github.com/cloudify-cosmo/cloudify-openstack-plugin.git
pip install -e cloudify-openstack-plugin

export HANDLER_CONFIGURATION=/path/to/sample-handler-configuration.yaml
nosetests -s cosmo_tester/test_suites/test_blueprints/nodecellar_test.py:OpenStackNodeCellarTest

export HANDLER_CONFIGURATION=/path/to/sample-handler-configuration.yaml
nosetests -s system_tests/test_openstack_blueprint/nodecellar_test.py:OpenStackNodeCellarTest

  Where:<br />
  * ```external```: Used to specify the tests package source repository, branch and git credentials. If this property is not provided, the framework will attempt to load the test modules from the system-tests package source.<br />
  * ```tests```: Used to define the path for test groups or a specific test module.<br />

* Upon execution of a single test or a test suite, a ```handler_configuration``` is assigned to it from an available configurations list.
  Using different ```handler_configurations``` allows for test suite executions to be distributed across all the available environment regions
  and run in parallel without interference.

  A standard handler configuration is defined like so:

...

Where:<br />
* ```handler```: Used to define the handler's module name which will be used as part of the test suite.
                A handler is an environment specific module initialized prior to the test execution that implements these [BaseHandler](https://github.com/cloudify-cosmo/cloudify-system-tests/blob/master/cosmo_tester/framework/handlers.py#L86)
                interface functions:<br />
                - __before_bootstrap__<br />
                - __after_bootstrap__<br />
                - __after_teardown__<br />
                The handler object also holds a cleanup class that implements a [BaseCleanupContext](https://github.com/cloudify-cosmo/cloudify-system-tests/blob/master/cosmo_tester/framework/handlers.py#L25) interface the following functions:<br />
                - __cleanup__ - Cleans resources created by each test.<br />
                - __cleanup_all__ - Cleans *all* resources, including resources that were not created by the test.<br />
                The system-test framework wil first try to import the handler module from the external path i.e ```{EXTERNAL}/system_tests/{HANDLER_NAME}.py``` and in case it was not found, will fall back to ```suites.handlers.{HANDLER_NAME}.py```.
                To learn more about handlers, checkout the [openstack_handler](https://github.com/cloudify-cosmo/cloudify-openstack-plugin/blob/master/system_tests/openstack_handler.py)
* ```external```: Used to define the handler's package source repository.<br />
* ```inputs```: Used to define the name of the specific environment inputs.yaml file to use. Input files are located under '/suites/configurations'.<br />
* ```manager_blueprint```: Used to define the manager blueprint file name. The actual file will be taken from the [cloudify-manager-blueprints](https://github.com/cloudify-cosmo/cloudify-manager-blueprints) repository.<br />
* ```manager_blueprint_override```: Used to define specific overrides to the manager blueprint used by the test suite.<br />
* ```env```: Used to define a unique environment identifier.<br />
* ```tags```: Used to define the actual execution environment defined in the handler configuration.<br />
             A test suite may use any of the available ```handler_configurations``` as long as the ```requires``` field matches the ```tags``` stated in the ```test_suite``` definition.<br />
* ```properties```: Used to define environment related properties such as image_id for the specified region. e.g. for ```{my_image_id: afd32-312d}``` the following applies in tests: ```self.env.my_image_id == 'afd32-312d'```.<br />
* ```inputs_override```: Used to override (or add) an entry to the ```inputs.yaml``` file. Dot notation may be used to override nested fields.<br />