-The OPNFV Rally scenarios are based on the collection of the actual Rally scenarios:
-
- * authenticate
- * cinder
- * glance
- * heat
- * keystone
- * neutron
- * nova
- * quotas
- * requests
-
-A basic SLA (stop test on errors) has been implemented.
-
-The Rally testcases are distributed across two Tiers:
-
- * Smoke Tier - Test Case 'rally_sanity'
- * Components Tier - Test case 'rally_full'
-
-NOTE: Test case 'rally_sanity' executes a limited number of Rally smoke test
-cases. Test case 'rally_full' executes the full defined set of Rally tests.
-
-
-Refstack-client to run Defcore testcases
------------------------------------------
-
-Refstack-client `[8]`_ is a command line utility that allows you to
-execute Tempest test runs based on configurations you specify.
-It is the official tool to run Defcore `[9]`_ testcases,
-which focuses on testing interoperability between OpenStack clouds.
-
-Refstack-client is integrated in Functest, consumed by Dovetail, which
-intends to define and provide a set of OPNFV related validation criteria
-that will provide input for the evaluation of the use of OPNFV trademarks.
-This progress is under the guideline of Compliance Verification Program(CVP).
-
-Defcore testcases
-^^^^^^^^^^^^^^^^^^
-
-*Danube Release*
-
-Set of DefCore tempest test cases not flagged and required.
-According to `[10]`_, some tests are still flagged due to outstanding bugs
-in the Tempest library, particularly tests that require SSH. Refstack developers
-are working on correcting these bugs upstream. Please note that although some tests
-are flagged because of bugs, there is still an expectation that the capabilities
-covered by the tests are available. It only contains Openstack core compute
-(no object storage). The approved guidelines (2016.08) are valid for Kilo,
-Liberty, Mitaka and Newton releases of OpenStack.
-The list can be generated using the Rest API from RefStack project:
-https://refstack.openstack.org/api/v1/guidelines/2016.08/tests?target=compute&type=required&alias=true&flag=false
-
-Running methods
-^^^^^^^^^^^^^^^
-
-Two running methods are provided after refstack-client integrated into
-Functest, Functest command line and manually, respectively.
-
-By default, for Defcore test cases run by Functest command line,
-are run followed with automatically generated
-configuration file, i.e., refstack_tempest.conf. In some circumstances,
-the automatic configuration file may not quite satisfied with the SUT,
-Functest also inherits the refstack-client command line and provides a way
-for users to set its configuration file according to its own SUT manually.
-
-*command line*
-
-Inside the Functest container, first to prepare Functest environment:
-
-::
-
- functest env prepare
-
-then to run default defcore testcases by using refstack-client:
-
-::
-
- functest testcase run refstack_defcore
-
-In OPNFV Continuous Integration(CI) system, the command line method is used.
-
-*manually*
-
-Inside the Functest container, first to prepare the refstack virtualenv:
-
-::
-
- cd /home/opnfv/repos/refstack-client
- source .venv/bin/activate
-
-then prepare the tempest configuration file and the testcases want to run with the SUT,
-run the testcases with:
-
-::
-
- ./refstack-client test -c <Path of the tempest configuration file to use> -v --test-list <Path or URL of test list>
-
-using help for more information:
-
-::
-
- ./refstack-client --help
- ./refstack-client test --help
-
-Reference tempest configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-*command line method*
-
-When command line method is used, the default tempest configuration file
-is generated by Rally.
-
-*manually*
-
-When running manually is used, recommended way to generate tempest configuration
-file is:
-
-::
-
- cd /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/refstack_client
- python tempest_conf.py
-
-a file called tempest.conf is stored in the current path by default, users can do
-some adjustment according to the SUT:
-
-::
-
- vim refstack_tempest.conf
-
-a reference article can be used `[15]`_.
-
-
-snaps_smoke
-------------
-
-This test case contains tests that setup and destroy environments with VMs with
-and without Floating IPs with a newly created user and project. Set the config
-value snaps.use_floating_ips (True|False) to toggle this functionality. When
-the config value of snaps.use_keystone is True, Functest must have access
-the cloud's private network.
-This suite consists in 38 tests (test duration < 10 minutes)
-
-
-SDN Controllers
----------------
-
-There are currently 3 available controllers:
-
- * OpenDaylight (ODL)
- * ONOS
- * OpenContrail (OCL)
-
-OpenDaylight
-^^^^^^^^^^^^
-
-The OpenDaylight (ODL) test suite consists of a set of basic tests inherited
-from the ODL project using the Robot `[11]`_ framework.
-The suite verifies creation and deletion of networks, subnets and ports with
-OpenDaylight and Neutron.
-
-The list of tests can be described as follows:
-
- * Basic Restconf test cases
- * Connect to Restconf URL
- * Check the HTTP code status
-
- * Neutron Reachability test cases
- * Get the complete list of neutron resources (networks, subnets, ports)
-
- * Neutron Network test cases
- * Check OpenStack networks
- * Check OpenDaylight networks
- * Create a new network via OpenStack and check the HTTP status code returned by Neutron
- * Check that the network has also been successfully created in OpenDaylight
-
- * Neutron Subnet test cases
- * Check OpenStack subnets
- * Check OpenDaylight subnets
- * Create a new subnet via OpenStack and check the HTTP status code returned by Neutron
- * Check that the subnet has also been successfully created in OpenDaylight
-
- * Neutron Port test cases
- * Check OpenStack Neutron for known ports
- * Check OpenDaylight ports
- * Create a new port via OpenStack and check the HTTP status code returned by Neutron
- * Check that the new port has also been successfully created in OpenDaylight
-
- * Delete operations
- * Delete the port previously created via OpenStack
- * Check that the port has been also successfully deleted in OpenDaylight
- * Delete previously subnet created via OpenStack
- * Check that the subnet has also been successfully deleted in OpenDaylight
- * Delete the network created via OpenStack
- * Check that the network has also been successfully deleted in OpenDaylight
-
-Note: the checks in OpenDaylight are based on the returned HTTP status
-code returned by OpenDaylight.
-
-
-ONOS
-^^^^
-
-TestON Framework is used to test the ONOS SDN controller functions.
-The test cases deal with L2 and L3 functions.
-The ONOS test suite can be run on any ONOS compliant scenario.
-
-The test cases are described as follows:
-
- * onosfunctest: The main executable file contains the initialization of
- the docker environment and functions called by FUNCvirNetNB and
- FUNCvirNetNBL3
-
- * FUNCvirNetNB
-
- * Create Network: Post Network data and check it in ONOS
- * Update Network: Update the Network and compare it in ONOS
- * Delete Network: Delete the Network and check if it's NULL in ONOS or
- not
- * Create Subnet: Post Subnet data and check it in ONOS
- * Update Subnet: Update the Subnet and compare it in ONOS
- * Delete Subnet: Delete the Subnet and check if it's NULL in ONOS or not
- * Create Port: Post Port data and check it in ONOS
- * Update Port: Update the Port and compare it in ONOS
- * Delete Port: Delete the Port and check if it's NULL in ONOS or not
-
- * FUNCvirNetNBL3