X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Fuserguide%2Findex.rst;h=d2467df710f4c4961cf89037be5193fc67f80e45;hb=ef43b6cbc6b445762dd7d48491dfe670bac2f710;hp=60bbc5b1a17757241ba71ef2d8593a8bd69bb3ae;hpb=5506086371536397dc532f2da7ae2bf420c260d6;p=functest.git diff --git a/docs/userguide/index.rst b/docs/userguide/index.rst index 60bbc5b1a..d2467df71 100644 --- a/docs/userguide/index.rst +++ b/docs/userguide/index.rst @@ -12,24 +12,45 @@ OPNFV FUNCTEST user guide 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 ^^^^^^^^^ @@ -50,7 +71,8 @@ Given the script **ping.sh**:: 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 +-------------+ +-------------+ @@ -68,7 +90,7 @@ on the public network and verify that 2 instances can talk on a private network: | | to VM2 | | | +------------------->| | | | | | - | | Stablish SSH | | + | | Establish SSH | | | | connection to VM2 | | | | through floating IP| | | +------------------->| | @@ -88,15 +110,16 @@ on the public network and verify that 2 instances can talk on a private network: +-------------+ +-------------+ 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 +-------------+ +-------------+ @@ -123,7 +146,7 @@ properly working:: +-------------+ +-------------+ 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. @@ -132,7 +155,7 @@ Tempest 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 @@ -143,22 +166,25 @@ Rally generates automatically the Tempest configuration file **tempest.conf**. 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 @@ -183,13 +209,20 @@ The OPNFV Rally scenarios are based on the collection of the actual Rally scenar * 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) @@ -205,42 +238,41 @@ OpenDaylight and Neutron. 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 @@ -271,27 +303,81 @@ The test cases are described as follows: * 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 @@ -316,67 +402,71 @@ The Clearwater architecture is described as follows: :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 @@ -391,18 +481,16 @@ Based on results collected in CI, a test dashboard is dynamically generated. 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_. @@ -416,3 +504,4 @@ IRC support chan: #opnfv-testperf .. _`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