* *connection_check*
- * *api_check*
- * *snaps_health_check*
-Connection_check consists in 9 test cases (test duration < 5s) checking the
+Connection_check consists in test cases (test duration < 5s) checking the
connectivity with Glance, Keystone, Neutron, Nova and the external network.
-Api_check verifies the retrieval of OpenStack clients: Keystone, Glance,
-Neutron and Nova and may perform some simple queries. When the config value of
-snaps.use_keystone is True, functest must have access to the cloud's private
-network. This suite consists in 49 tests (test duration < 2 minutes).
-
-Snaps_health_check creates a VM with a single port with an IPv4 address that
-is assigned by DHCP and then validates the expected IP with the actual.
-
Self-obviously, successful completion of the 'healthcheck' testcase is a
necessary pre-requisite for the execution of all other test Tiers.
The Tempest testcases are distributed across three
Tiers:
- * Smoke Tier - Test Case 'tempest_smoke_serial'
- * Components Tier - Test case 'tempest_full_parallel'
+ * Smoke Tier - Test Case 'tempest_smoke'
+ * Components Tier - Test case 'tempest_full'
* Neutron Trunk Port - Test case 'neutron_trunk'
* OpenStack interop testcases - Test case 'refstack_defcore'
* Testing and verifying RBAC policy enforcement - Test case 'patrole'
-NOTE: Test case 'tempest_smoke_serial' executes a defined set of tempest smoke
-tests with a single thread (i.e. serial mode). Test case
-'tempest_full_parallel' executes all defined Tempest tests using several
-concurrent threads (i.e. parallel mode). The number of threads activated
-corresponds to the number of available logical CPUs.
+NOTE: Test case 'tempest_smoke' executes a defined set of tempest smoke
+tests. Test case 'tempest_full' executes all defined Tempest tests.
NOTE: The 'neutron_trunk' test set allows to connect a VM to multiple VLAN
separated networks using a single NIC. The feature neutron trunk ports have
cases. Test case 'rally_full' executes the full defined set of Rally tests.
-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.
-Please note that When the configuration value of snaps.use_keystone is True,
-Functest must have access the cloud's private network.
-This suite consists in 120 tests (test duration ~= 50 minutes)
-
-
SDN Controllers
---------------
:align: center
:alt: vIMS architecture
+heat_ims
+^^^^^^^^
+The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
+architectural framework for delivering IP multimedia services.
-cloudify_ims_perf
-^^^^^^^^^^^^^^^^^
-This testcase extends the cloudify_ims test case.
-The first part is similar but the testing part is different.
-The testing part consists in automating a realistic signaling load on the vIMS
-using an Ixia loader (proprietary tools)
-
- - You need to have access to an Ixia licence server defined in the
- configuration file and have ixia image locally.
-
-This test case is available but not declared in testcases.yaml. The declaration
-of the testcase is simple, connect to your functest-vnf docker, add the
-following section in
-/usr/lib/python2.7/site-packacges/functest/ci/testcases.yaml::
-
- -
- case_name: cloudify_ims_perf
- project_name: functest
- criteria: 80
- blocking: false
- description: >-
- Stress tests based on Cloudify. Ixia loader images and access to Ixia
- server license.
- dependencies:
- installer: ''
- scenario: 'os-nosdn-nofeature-ha'
- run:
- module: 'functest.opnfv_tests.vnf.ims.cloudify_ims_perf'
- class: 'CloudifyImsPerf'
+vIMS has been integrated in Functest to demonstrate the capability to deploy a
+relatively complex NFV scenario on the OPNFV platform. The deployment of a
+complete functional VNF allows the test of most of the essential functions
+needed for a NFV platform.
+
+The goal of this test suite consists of:
+
+* deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF using
+ OpenStack Heat orchestrator based on a HOT template defined in `[17]`_
+* run suite of signaling tests on top of this VNF
+
+The Clearwater architecture is described as follows:
+
+.. figure:: ../../../images/clearwater-architecture-v2.png
+ :align: center
+ :alt: vIMS architecture
vyos-vrouter
^^^^^^^^^^^^
designed to be run with no cloud provider configured.
-.. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
-.. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
+.. _`[2]`: https://docs.openstack.org/tempest/latest/
+.. _`[3]`: https://rally.readthedocs.io/en/latest/index.html
.. _`[5]`: https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/blob/master/openstack-blueprint.yaml
.. _`[8]`: https://github.com/openstack/refstack-client
-.. _`[9]`: https://github.com/openstack/defcore
+.. _`[9]`: https://github.com/openstack/interop
.. _`[10]`: https://github.com/openstack/interop/blob/master/2016.08/procedure.rst
.. _`[11]`: http://robotframework.org/
-.. _`[12]`: http://docs.opnfv.org/en/latest/submodules/functest/docs/testing/user/userguide/index.html
.. _`[13]`: https://wiki.opnfv.org/display/PROJ/SNAPS-OO
.. _`[14]`: https://github.com/oolorg/opnfv-functest-vrouter
-.. _`[15]`: https://www.rebaca.com/abot-test-orchestration-tool/
+.. _`[15]`: https://www.rebaca.com/what-we-do/abot-5g-network-simulator/
.. _`[16]`: https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md
+.. _`[17]`: https://github.com/Metaswitch/clearwater-heat/blob/release-129/clearwater.yaml
Code Review / functest.git / blobdiff