Define create_snapshot() and clean() in TestCase

They replace the former calls in run_tests which are not suitable for all
test cases. Now any test case can define how to clean its resources.

If the snapshot cannot be created, the test case is considered as
failed. Only a message is printed if any failure during cleaning.

It also defines a new class called OSGCTestCase useful for test cases
which don't clean their OpenStack resources.
All test cases located in opnfv_tests/openstack inherit from it to
keep the global behavior unchanged.

It also deletes exit instructions in openstack_clean and
openstack_snapshot, removes clean flags in testcases.yaml and updates
the related utils.

All Docs are modified as well.

JIRA: FUNCTEST-438

Change-Id: I8938e6255708012380389763a24059ace4ce45d8
Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com>

2 files changed, 10 insertions, 18 deletions

diff --git a/docs/com/pres/framework/framework.md b/docs/com/pres/framework/framework.md
index 1b07a8e0b..40d5a6a70 100644
--- a/docs/com/pres/framework/framework.md
+++ b/docs/com/pres/framework/framework.md
@@ -59,12 +59,14 @@ base model for single test case
 
 ### methods
 
-| Method            | Purpose                                    |
-|-------------------|--------------------------------------------|
-| run(**kwargs)     | run the test case                          |
-| is_successful()   | interpret the results of the test case     |
-| get_duration()    | return the duration of the test case       |
-| push_to_db()      | push the results of the test case to the DB|
+| Method            | Purpose                       |
+|-------------------|-------------------------------|
+| run(**kwargs)     | run the test case             |
+| is_successful()   | interpret the results         |
+| get_duration()    | return the duration           |
+| push_to_db()      | push the results to the DB    |
+| create_snapshot() | save the testing environement |
+| clean()           | clean the resources           |
 
 
 ### run(**kwargs)
@@ -136,7 +138,6 @@ case_name: first
 project_name: functest
 criteria: 100
 blocking: true
-clean_flag: false
 description: ''
 dependencies:
     installer: ''
@@ -204,7 +205,6 @@ case_name: second
 project_name: functest
 criteria: 100
 blocking: true
-clean_flag: false
 description: ''
 dependencies:
     installer: ''
@@ -238,7 +238,6 @@ case_name: third
 project_name: functest
 criteria: 100
 blocking: true
-clean_flag: false
 description: ''
 dependencies:
     installer: ''
@@ -294,7 +293,6 @@ case_name: fourth
 project_name: functest
 criteria: 100
 blocking: true
-clean_flag: false
 description: ''
 dependencies:
     installer: ''
diff --git a/docs/testing/user/userguide/runfunctest.rst b/docs/testing/user/userguide/runfunctest.rst
index 07b5b8a60..c155e6090 100644
--- a/docs/testing/user/userguide/runfunctest.rst
+++ b/docs/testing/user/userguide/runfunctest.rst
@@ -561,14 +561,9 @@ the Functest environment (i.e. CLI command 'functest env prepare') to snapshot
 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
@@ -660,7 +655,6 @@ For a given test case we defined:
   * 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