Introduction
============
-The goal of this document is to describe the Functest test cases as well as
-provide a procedure to execute them.
+The goal of this document is to describe the OPNFV Functest test cases and to
+provide a procedure to execute them. In the OPNFV Colorado system release,
+a Functest CLI utility is introduced for easier execution of test procedures.
-A presentation has been created for the first OPNFV Summit `[4]`_.
+An overview presentation has been created for the first OPNFV Summit `[4]`_.
-This document is a continuation of the Functest Configuration Guide`[1]`_ and it
-is assumed that the Functest Docker container is properly deployed.
+This document is a continuation of the OPNFV Functest Configuration Guide `[1]`_.
-**IMPORTANT**: All the instructions described in this guide must be performed
-inside the container.
+**IMPORTANT**: It is assumed here that the Functest Docker container is already
+properly deployed and that all instructions described in this guide are to be
+performed from *inside* the deployed Functest Docker container.
.. include:: ./introduction.rst
-The different test cases are described in the section hereafter.
+The different test cases are described in the remaining sections of this document.
VIM (Virtualized Infrastructure Manager)
----------------------------------------
+Healthcheck
+^^^^^^^^^^^
+In Colorado release a new Tier 'healthcheck' with one testcase 'healthcheck'
+is introduced. The healthcheck testcase verifies that some basic IP connectivity
+and essential operations of OpenStack functionality over the command line are
+working correctly.
+
+In particular, the following verifications are performed:
+
+ * DHCP agent functionality for IP address allocation
+ * Openstack Authentication management functionality via the Keystone API
+ * OpenStack Image management functionality via the Glance API
+ * OpenStack Block Storage management functionality via the Cinder API
+ * OpenStack Networking management functionality via the Neutron API
+ * Openstack Compute management functionality via the NOVA API
+
+Self-obviously, successful completion of the 'healthcheck' testcase is a
+necessary pre-requisite for the execution of all other test Tiers.
+
+
vPing_ssh
^^^^^^^^^
The goal of this test is to establish an SSH connection using a floating IP
-on the public network and verify that 2 instances can talk on a private network::
+on the Public/External network and verify that 2 instances can talk over a Private
+Tenant network::
vPing_ssh test case
+-------------+ +-------------+
| | to VM2 | |
| +------------------->| |
| | | |
- | | Stablish SSH | |
+ | | Establish SSH | |
| | connection to VM2 | |
| | through floating IP| |
| +------------------->| |
+-------------+ +-------------+
This test can be considered as an "Hello World" example.
-It is the first basic use case which shall work on any deployment.
+It is the first basic use case which **must** work on any deployment.
vPing_userdata
^^^^^^^^^^^^^^
-This test case is similar to vPing_ssh but without the use of floating ips
-and the public network. It only checks that 2 instances can talk to each other
-on a private network but it also verifies that the Nova metadata service is
-properly working::
+This test case is similar to vPing_ssh but without the use of Floating IPs
+and the Public/External network to transfer the ping script.
+Instead, it uses Nova metadata service to pass it to the instance at booting time.
+As vPing_ssh, it checks that 2 instances can talk to
+each other on a Private Tenant network::
vPing_userdata test case
+-------------+ +-------------+
+-------------+ +-------------+
When the second VM boots it will execute the script passed as userdata
-automatically and the ping will be detected capturing periodically the output
+automatically. The ping will be detected by periodically capturing the output
in the console-log of the second VM.
Tempest `[2]`_ is the reference OpenStack Integration test suite.
It is a set of integration tests to be run against a live OpenStack cluster.
-Tempest has batteries of tests for:
+Tempest has suites of tests for:
* OpenStack API validation
* Scenarios
Before running the actual test cases,
Functest creates the needed resources (user, tenant) and
updates the appropriate parameters into the configuration file.
+
When the Tempest suite is executed, each test duration is measured and the full
-console output is stored in a *log* file for further analysis.
+console output is stored to a *log* file for further analysis.
-As an addition of Arno, Brahmaputra runs a customized set of Tempest test cases.
-The list is specificed through *--tests-file* when executing the Rally command.
-This option has been introduced in the version 0.1.2 of the Rally framework.
+The Tempest testcases are distributed accross two
+Tiers:
-This customized list contains more than 200 Tempest test cases and can be divided
-into two main sections:
+ * Smoke Tier - Test Case 'tempest_smoke_serial'
+ * Openstack Tier - Test case 'tempest_full_parallel'
- 1) Set of Tempest smoke test cases
- 2) Set of test cases from DefCore list `[8]`_
+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.
The goal of the Tempest test suite is to check the basic functionalities of the
-different OpenStack components on an OPNFV fresh installation using
-the corresponding REST API interfaces.
+different OpenStack components on an OPNFV fresh installation, using the
+corresponding REST API interfaces.
Rally bench test suites
* quotas
* requests
-A basic SLA (stop test on errors) have been implemented.
+A basic SLA (stop test on errors) has been implemented.
+
+The Rally testcases are distributed accross two Tiers:
+
+ * Smoke Tier - Test Case 'rally_sanity'
+ * Openstack 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.
SDN Controllers
---------------
-Brahmaputra introduces new SDN controllers.
There are currently 2 available controllers:
* OpenDaylight (ODL)
The list of tests can be described as follows:
- * Restconf.basic: Get the controller modules via Restconf
- * Neutron.Networks
-
- * Check OpenStack Networks :: Checking OpenStack Neutron for known networks
- * Check OpenDaylight Networks :: Checking OpenDaylight Neutron API
- * Create Network :: Create new network in OpenStack
- * Check Network :: Check Network created in OpenDaylight
- * Neutron.Networks :: Checking Network created in OpenStack are pushed
-
- * Neutron.Subnets
-
- * Check OpenStack Subnets :: Checking OpenStack Neutron for known Subnets
- * Check OpenDaylight subnets :: Checking OpenDaylight Neutron API
- * Create New subnet :: Create new subnet in OpenStack
- * Check New subnet :: Check new subnet created in OpenDaylight
- * Neutron.Subnets :: Checking Subnets created in OpenStack are pushed
+ * Basic Restconf test cases
+ * Connect to Restconf URL
+ * Check the HTTP code status
- * Neutron.Ports
+ * Neutron Reachability test cases
+ * Get the complete list of neutron resources (networks, subnets, ports)
- * Check OpenStack ports :: Checking OpenStack Neutron for known ports
- * Check OpenDaylight ports :: Checking OpenDaylight Neutron API
- * Create New Port :: Create new port in OpenStack
- * Check New Port :: Check new subnet created in OpenDaylight
- * Neutron.Ports :: Checking Port created in OpenStack are pushed
+ * 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
- * Delete Ports
+ * 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
- * Delete previously created subnet in OpenStack
- * Check subnet deleted in OpenDaylight
- * Check subnet deleted in OpenStack
+ * 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 network
+ * Delete operations
+ * Delete the port previously created via OpenStack
+ * Check that the port has been also succesfully 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 succesfully deleted in OpenDaylight
- * Delete previously created network in OpenStack
- * Check network deleted in OpenDaylight
- * Check network deleted in OpenStack
+Note: the checks in OpenDaylight are based on the returned HTTP status
+code returned by OpenDaylight.
ONOS
* FUNCvirNetNBL3
- * Create Router: Post dataes for create Router and check it in ONOS
+ * Create Router: Post data for create Router and check it in ONOS
* Update Router: Update the Router and compare it in ONOS
- * Delete Router: Delete the Router dataes and check it in ONOS
- * Create RouterInterface: Post RouterInterface data to an exist Router
+ * Delete Router: Delete the Router data and check it in ONOS
+ * Create RouterInterface: Post Router Interface data to an existing Router
and check it in ONOS
* Delete RouterInterface: Delete the RouterInterface and check the Router
- * Create FloatingIp: Post dataes for create FloatingIp and check it in
- ONOS
+ * Create FloatingIp: Post data for create FloatingIp and check it in ONOS
* Update FloatingIp: Update the FloatingIp and compare it in ONOS
- * Delete FloatingIp: Delete the FloatingIp and check if it's NULL in
- ONOS or not
- * Create External Gateway: Post dataes for create External Gateway to an
- exit Router and check it
- * Update External Gateway: Update the External Gateway and compare it
- * Delete External Gateway: Delete the External Gateway and check if it's
- NULL in ONOS or not
+ * Delete FloatingIp: Delete the FloatingIp and check that it is 'NULL' in
+ ONOS
+ * Create External Gateway: Post data to create an External Gateway for an
+ existing Router and check it in ONOS
+ * Update External Gateway: Update the External Gateway and compare the change
+ * Delete External Gateway: Delete the External Gateway and check that it is
+ 'NULL' in ONOS
Features
--------
+Most of the features have been developped by feature projects.
+Security_scan has been initiated in Functest repository but should soon
+be declared in its own repository as well.
+
+Please refer to the dedicated feature user guides for details:
+
+ * bgpvpn: http://artifacts.opnfv.org/sdnvpn/colorado/docs/userguide/index.html
+ * copper: http://artifacts.opnfv.org/copper/colorado/docs/userguide/index.html
+ * doctor: http://artifacts.opnfv.org/doctor/colorado/userguide/index.html
+ * domino: http://artifacts.opnfv.org/domino/docs/userguide-single/index.html
+ * moon: http://artifacts.opnfv.org/moon/docs/userguide/index.html
+ * multisites: http://artifacts.opnfv.org/multisite/docs/userguide/index.html
+ * onos-sfc: http://artifacts.opnfv.org/onosfw/colorado/userguide/index.html
+ * odl-sfc: http://artifacts.opnfv.org/sfc/colorado/userguide/index.html
+ * promise: http://artifacts.opnfv.org/promise/colorado/docs/userguide/index.html
+
+security_scan
+^^^^^^^^^^^^^
+
+Security Scanning, is a project to insure security compliance and vulnerability
+checks, as part of an automated CI / CD platform delivery process.
+
+The project makes use of the existing SCAP format[6] to perform deep scanning of
+NFVi nodes, to insure they are hardened and free of known CVE reported vulnerabilities.
+
+The SCAP content itself, is then consumed and run using an upstream opensource tool
+known as OpenSCAP[7].
+
+The OPNFV Security Group have developed the code that will called by the OPNFV Jenkins
+build platform, to perform a complete scan. Resulting reports are then copied to the
+OPNFV functest dashboard.
+
+The current work flow is as follows:
+
+ * Jenkins Build Initiated
+ * security_scan.py script is called, and a config file is passed to the script as
+ an argument.
+ * The IP addresses of each NFVi node (compute / control) are gathered
+ * A scan profile is matched to the node type.
+ * The OpenSCAP application is remotely installed onto each target node gathered
+ on step 3, using upstream packaging (rpm and .deb).
+ * A scan is made against each node gathered within step 3.
+ * HTML Reports are downloaded for rendering on a dashboard.
+ * If the config file value 'clean' is set to 'True' then the application installed in
+ step 5 is removed, and all reports created at step 6 are deleted.
+
+At present, only the Apex installer is supported, with support for other installers due
+within D-release.
+
+
+
+VNF
+---
+
+
vIMS
^^^^
The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
:alt: vIMS architecture
-
-Promise
-^^^^^^^
-
-Promise provides a basic set of test cases as part of Brahmaputra.
-
-The available 33 test cases can be grouped into 7 test suites:
-
- #. Add a new OpenStack provider into resource pool: Registers
- OpenStack into a new resource pool and adds more capacity associated
- with this pool.
-
- #. Allocation without reservation: Creates a new server in OpenStack
- and adds a new allocation record in Promise shim-layer.
-
- #. Allocation using reservation for immediate use: Creates a resource
- reservation record with no start/end time and immediately creates a new
- server in OpenStack and add a new allocation record in Promise
- shim-layer.
-
- #. Reservation for future use: Creates a resource reservation record
- for a future start time, queries, modifies and cancels the newly created
- reservation.
-
- #. Capacity planning: Decreases and increases the available capacity
- from a provider in the future and queries the available collections and
- utilizations.
-
- #. Reservation with conflict: Tries to create reservations for
- immediate and future use with conflict.
-
- #. Cleanup test allocations: Destroys all allocations in OpenStack.
-
-
-SDNVPN
+parser
^^^^^^
-Many telecom network functions are relying on layer-3 infrastructure services,
-within a VNF between components, or towards existing external networks.
-In many cases, these external networks are implemented in MPLS/BGP technology in
-existing service provider wide-area-networks (WAN). This proven technology
-provides a good mechanism for inter-operation of a NFV Infrastructure (NFVI)
-and WAN.
-The SDNVPN project defined a bgpvpn suite.
-This bgpvpn suite deals with 2 Tempest cases dedicated to the test of the
-OpenStack bgpvpn API:
+See parser user guide for details: `[12]`_
- * test_create_bgpvpn
- * test_create_bgpvpn_as_non_admin_fail
.. include:: ./runfunctest.rst
+
Test results
============
-For Brahmaputra test results, see the functest results document at `[12]`_
-
-Note that the results are documented per scenario basis. Although most of the test
-cases might show the same output, some of them are not supported by
-certain scenario. Please select the appropriate scenario and compare the results
-to the referenced in the documentation.
+Manual testing
+--------------
+
+In manual mode test results are displayed in the console and result files
+are put in /home/opnfv/functest/results.
+
+Automated testing
+--------------
+
+In automated mode, test results are displayed in jenkins logs, a summary is provided
+at the end of the job and can be described as follow::
+
+ +==================================================================================================================================================+
+ | FUNCTEST REPORT |
+ +==================================================================================================================================================+
+ | |
+ | Deployment description: |
+ | INSTALLER: fuel |
+ | SCENARIO: os-odl_l2-nofeature-ha |
+ | BUILD TAG: jenkins-functest-fuel-baremetal-daily-master-324 |
+ | CI LOOP: daily |
+ | |
+ +=========================+===============+============+===============+===========================================================================+
+ | TEST CASE | TIER | DURATION | RESULT | URL |
+ +=========================+===============+============+===============+===========================================================================+
+ | healthcheck | healthcheck | 03:07 | PASS | |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | vping_ssh | smoke | 00:56 | PASS | http://testresults.opnfv.org/test/api/v1/results/57ac13d79377c54b278bd4c1 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | vping_userdata | smoke | 00:41 | PASS | http://testresults.opnfv.org/test/api/v1/results/57ac14019377c54b278bd4c2 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | tempest_smoke_serial | smoke | 16:05 | FAIL | http://testresults.opnfv.org/test/api/v1/results/57ac17ca9377c54b278bd4c3 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | rally_sanity | smoke | 12:19 | PASS | http://testresults.opnfv.org/test/api/v1/results/57ac1aad9377c54b278bd4cd |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | odl | sdn_suites | 00:24 | PASS | http://testresults.opnfv.org/test/api/v1/results/57ac1ad09377c54b278bd4ce |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | promise | features | 00:41 | PASS | http://testresults.opnfv.org/test/api/v1/results/57ac1ae59377c54b278bd4cf |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+
+Results are automatically pushed to the test results database, some additional
+result files are pushed to OPNFV artifact web sites.
+
+Based on the results stored in the result database, a `Functest reporting`_
+portal is also automatically updated. This portal provides information on:
+
+ * The overall status per scenario and per installer
+ * Tempest: Tempest test case including reported errors per scenario and installer
+ * vIMS: vIMS details per scenario and installer
+
+.. figure:: ../images/functest-reporting-status.png
+ :align: center
+ :alt: Functest reporting portal Fuel status page
Test Dashboard
References
==========
-.. _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/#functional-testing-installation
+.. _`[1]`: http://artifacts.opnfv.org/functest/colorado/docs/configguide/#
.. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
.. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
.. _`[4]`: http://events.linuxfoundation.org/sites/events/files/slides/Functest%20in%20Depth_0.pdf
.. _`[5]`: https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/blob/master/openstack-blueprint.yaml
-.. _`[6]`: https://wiki.opnfv.org/opnfv_test_dashboard
-.. _`[7]`: http://testresults.opnfv.org/testapi/test_projects/functest/cases
-.. _`[8]`: https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
+.. _`[6]`: https://scap.nist.gov/
+.. _`[7]`: https://github.com/OpenSCAP/openscap
.. _`[9]`: https://git.opnfv.org/cgit/functest/tree/testcases/VIM/OpenStack/CI/libraries/os_defaults.yaml
-.. _`[10]`: https://git.opnfv.org/cgit/functest/tree/testcases/VIM/OpenStack/CI/rally_cert/task.yaml
.. _`[11]`: http://robotframework.org/
-.. _`[12]`: http://artifacts.opnfv.org/functest/brahmaputra/docs/results/index.html
+.. _`[12]`: http://artifacts.opnfv.org/parser/colorado/docs/userguide/index.html
OPNFV main site: opnfvmain_.
.. _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
.. _`config_test.py` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.py
.. _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml
+.. _`Functest reporting`: http://testresults.opnfv.org/reporting/functest/release/colorado/index-status-fuel.html
Code Review / functest.git / blobdiff