and
root@22e436918db0:~/repos/functest/ci# functest testcase run vping_ssh
- Executing command: 'python /home/opnfv/repos/functest/ci/run_tests.py -t vping_ssh'
- 2016-06-30 11:50:31,861 - run_tests - INFO - Sourcing the OpenStack RC file...
2016-06-30 11:50:31,865 - run_tests - INFO - ============================================
2016-06-30 11:50:31,865 - run_tests - INFO - Running test case 'vping_ssh'...
2016-06-30 11:50:31,865 - run_tests - INFO - ============================================
all the OpenStack resources (images, networks, volumes, security groups, tenants,
users) so that an eventual cleanup does not remove any of these defaults.
-It is also called before running a test except if it is disabled by configuration
-in the testcases.yaml file (clean_flag=false). This flag has been added as some
-upstream tests already include their own cleaning mechanism (e.g. Rally).
-
The script **openstack_clean.py** which is located in
-*$REPOS_DIR/functest/functest/utils/* is normally called after a test execution. It is
-in charge of cleaning the OpenStack resources that are not specified in the
-defaults file generated previously which is stored in
+*$REPOS_DIR/functest/functest/utils/* is in charge of cleaning the OpenStack resources
+that are not specified in the defaults file generated previously which is stored in
*/home/opnfv/functest/conf/openstack_snapshot.yaml* in the Functest docker container.
It is important to mention that if there are new OpenStack resources created
* The scenario [controller]-[feature]-[mode], stored in DEPLOY_SCENARIO with
* controller = (odl|ocl|nosdn|onos)
- * feature = (ovs(dpdk)|kvm|sfc|bgpvpn|multisites|netready|ovs_dpdk_bar)
+ * feature = (ovs(dpdk)|kvm|sfc|bgpvpn|ovs_dpdk_bar)
* mode = (ha|noha)
The constraints per test case are defined in the Functest configuration file
-*/home/opnfv/repos/functest/functest/ci/testcases.yaml*::
+*/usr/local/lib/python2.7/dist-packages/functest/ci/testcases.yaml*::
tiers:
-
* the name of the test case
* the criteria (experimental): a criteria used to declare the test case as PASS or FAIL
* blocking: if set to true, if the test is failed, the execution of the following tests is canceled
- * clean_flag: shall the functect internal mechanism be invoked after the test
* the description of the test case
* the dependencies: a combination of 2 regex on the scenario and the installer name
* run: In Danube we introduced the notion of abstract class in order to harmonize the way to run internal, feature or vnf tests