docs/userguide/index.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 =========================
   5 OPNFV FUNCTEST user guide
   6 =========================
   7
   8 .. toctree::
   9    :maxdepth: 2
  10
  11
  12 Introduction
  13 ============
  14
  15 The goal of this document is to describe the Functest test cases as well as
  16 provide a procedure to execute them.
  17
  18 A presentation has been created for the first OPNFV Summit `[4]`_.
  19
  20 This document is a continuation of the Functest Configuration Guide`[1]`_ and it
  21 is assumed that the Functest Docker container is properly deployed.
  22
  23 **IMPORTANT**: All the instructions described in this guide must be performed
  24 inside the container.
  25
  26 .. include:: ./introduction.rst
  27
  28 The different test cases are described in the section hereafter.
  29
  30 VIM (Virtualized Infrastructure Manager)
  31 ----------------------------------------
  32
  33 vPing_ssh
  34 ^^^^^^^^^
  35
  36 Given the script **ping.sh**::
  37
  38     #!/bin/sh
  39     while true; do
  40         ping -c 1 $1 2>&1 >/dev/null
  41         RES=$?
  42         if [ "Z$RES" = "Z0" ] ; then
  43             echo 'vPing OK'
  44             break
  45         else
  46             echo 'vPing KO'
  47         fi
  48     sleep 1
  49     done
  50
  51
  52 The goal of this test is to establish an SSH connection using a floating IP
  53 on the public network and verify that 2 instances can talk on a private network::
  54
  55  vPing_ssh test case
  56  +-------------+                    +-------------+
  57  |             |                    |             |
  58  |             | Boot VM1 with IP1  |             |
  59  |             +------------------->|             |
  60  |   Tester    |                    |   System    |
  61  |             | Boot VM2           |    Under    |
  62  |             +------------------->|     Test    |
  63  |             |                    |             |
  64  |             | Create floating IP |             |
  65  |             +------------------->|             |
  66  |             |                    |             |
  67  |             | Assign floating IP |             |
  68  |             | to VM2             |             |
  69  |             +------------------->|             |
  70  |             |                    |             |
  71  |             | Stablish SSH       |             |
  72  |             | connection to VM2  |             |
  73  |             | through floating IP|             |
  74  |             +------------------->|             |
  75  |             |                    |             |
  76  |             | SCP ping.sh to VM2 |             |
  77  |             +------------------->|             |
  78  |             |                    |             |
  79  |             | VM2 executes       |             |
  80  |             | ping.sh to VM1     |             |
  81  |             +------------------->|             |
  82  |             |                    |             |
  83  |             |    If ping:        |             |
  84  |             |      exit OK       |             |
  85  |             |    else (timeout): |             |
  86  |             |      exit Failed   |             |
  87  |             |                    |             |
  88  +-------------+                    +-------------+
  89
  90 This test can be considered as an "Hello World" example.
  91 It is the first basic use case which shall work on any deployment.
  92
  93 vPing_userdata
  94 ^^^^^^^^^^^^^^
  95
  96 This test case is similar to vPing_ssh but without the use of floating ips
  97 and the public network. It only checks that 2 instances can talk to each other
  98 on a private network but it also verifies that the Nova metadata service is
  99 properly working::
 100
 101  vPing_userdata test case
 102  +-------------+                    +-------------+
 103  |             |                    |             |
 104  |             | Boot VM1 with IP1  |             |
 105  |             +------------------->|             |
 106  |             |                    |             |
 107  |             | Boot VM2 with      |             |
 108  |             | ping.sh as userdata|             |
 109  |             | with IP1 as $1.    |             |
 110  |             +------------------->|             |
 111  |   Tester    |                    |   System    |
 112  |             | VM2 exeutes ping.sh|    Under    |
 113  |             | (ping IP1)         |     Test    |
 114  |             +------------------->|             |
 115  |             |                    |             |
 116  |             | Monitor nova       |             |
 117  |             |  console-log VM 2  |             |
 118  |             |    If ping:        |             |
 119  |             |      exit OK       |             |
 120  |             |    else (timeout)  |             |
 121  |             |      exit Failed   |             |
 122  |             |                    |             |
 123  +-------------+                    +-------------+
 124
 125 When the second VM boots it will execute the script passed as userdata
 126 automatically and the ping will be detected capturing periodically the output
 127 in the console-log of the second VM.
 128
 129
 130 Tempest
 131 ^^^^^^^
 132
 133 Tempest `[2]`_ is the reference OpenStack Integration test suite.
 134 It is a set of integration tests to be run against a live OpenStack cluster.
 135 Tempest has batteries of tests for:
 136
 137   * OpenStack API validation
 138   * Scenarios
 139   * Other specific tests useful in validating an OpenStack deployment
 140
 141 Functest uses Rally `[3]`_ to run the Tempest suite.
 142 Rally generates automatically the Tempest configuration file **tempest.conf**.
 143 Before running the actual test cases,
 144 Functest creates the needed resources (user, tenant) and
 145 updates the appropriate parameters into the configuration file.
 146 When the Tempest suite is executed, each test duration is measured and the full
 147 console output is stored in a *log* file for further analysis.
 148
 149 As an addition of Arno, Brahmaputra runs a customized set of Tempest test cases.
 150 The list is specificed through *--tests-file* when executing the Rally command.
 151 This option has been introduced in the version 0.1.2 of the Rally framework.
 152
 153 This customized list contains more than 200 Tempest test cases and can be divided
 154 into two main sections:
 155
 156   1) Set of Tempest smoke test cases
 157   2) Set of test cases from DefCore list `[8]`_
 158
 159 The goal of the Tempest test suite is to check the basic functionalities of the
 160 different OpenStack components on an OPNFV fresh installation using
 161 the corresponding REST API interfaces.
 162
 163
 164 Rally bench test suites
 165 ^^^^^^^^^^^^^^^^^^^^^^^
 166
 167 Rally `[3]`_ is a benchmarking tool that answers the question:
 168
 169 *How does OpenStack work at scale?*
 170
 171 The goal of this test suite is to benchmark all the different OpenStack modules and
 172 get significant figures that could help to define Telco Cloud KPIs.
 173
 174 The OPNFV Rally scenarios are based on the collection of the actual Rally scenarios:
 175
 176  * authenticate
 177  * cinder
 178  * glance
 179  * heat
 180  * keystone
 181  * neutron
 182  * nova
 183  * quotas
 184  * requests
 185
 186 A basic SLA (stop test on errors) have been implemented.
 187
 188
 189 SDN Controllers
 190 ---------------
 191
 192 Brahmaputra introduces new SDN controllers.
 193 There are currently 2 available controllers:
 194
 195  * OpenDaylight (ODL)
 196  * ONOS
 197
 198 OpenDaylight
 199 ^^^^^^^^^^^^
 200
 201 The OpenDaylight (ODL) test suite consists of a set of basic tests inherited
 202 from the ODL project using the Robot `[11]`_ framework.
 203 The suite verifies creation and deletion of networks, subnets and ports with
 204 OpenDaylight and Neutron.
 205
 206 The list of tests can be described as follows:
 207
 208  * Restconf.basic: Get the controller modules via Restconf
 209  * Neutron.Networks
 210
 211    * Check OpenStack Networks :: Checking OpenStack Neutron for known networks
 212    * Check OpenDaylight Networks :: Checking OpenDaylight Neutron API
 213    * Create Network :: Create new network in OpenStack
 214    * Check Network :: Check Network created in OpenDaylight
 215    * Neutron.Networks :: Checking Network created in OpenStack are pushed
 216
 217  * Neutron.Subnets
 218
 219    * Check OpenStack Subnets :: Checking OpenStack Neutron for known Subnets
 220    * Check OpenDaylight subnets :: Checking OpenDaylight Neutron API
 221    * Create New subnet :: Create new subnet in OpenStack
 222    * Check New subnet :: Check new subnet created in OpenDaylight
 223    * Neutron.Subnets :: Checking Subnets created in OpenStack are pushed
 224
 225  * Neutron.Ports
 226
 227    * Check OpenStack ports :: Checking OpenStack Neutron for known ports
 228    * Check OpenDaylight ports :: Checking OpenDaylight Neutron API
 229    * Create New Port :: Create new port in OpenStack
 230    * Check New Port :: Check new subnet created in OpenDaylight
 231    * Neutron.Ports :: Checking Port created in OpenStack are pushed
 232
 233  * Delete Ports
 234
 235    * Delete previously created subnet in OpenStack
 236    * Check subnet deleted in OpenDaylight
 237    * Check subnet deleted in OpenStack
 238
 239  * Delete network
 240
 241    * Delete previously created network in OpenStack
 242    * Check network deleted in OpenDaylight
 243    * Check network deleted in OpenStack
 244
 245
 246 ONOS
 247 ^^^^
 248
 249 TestON Framework is used to test the ONOS SDN controller functions.
 250 The test cases deal with L2 and L3 functions.
 251 The ONOS test suite can be run on any ONOS compliant scenario.
 252
 253 The test cases are described as follows:
 254
 255  * onosfunctest: The main executable file contains the initialization of
 256    the docker environment and functions called by FUNCvirNetNB and
 257    FUNCvirNetNBL3
 258
 259  * FUNCvirNetNB
 260
 261    * Create Network: Post Network data and check it in ONOS
 262    * Update Network: Update the Network and compare it in ONOS
 263    * Delete Network: Delete the Network and check if it's NULL in ONOS or
 264      not
 265    * Create Subnet: Post Subnet data and check it in ONOS
 266    * Update Subnet: Update the Subnet and compare it in ONOS
 267    * Delete Subnet: Delete the Subnet and check if it's NULL in ONOS or not
 268    * Create Port: Post Port data and check it in ONOS
 269    * Update Port: Update the Port and compare it in ONOS
 270    * Delete Port: Delete the Port and check if it's NULL in ONOS or not
 271
 272  * FUNCvirNetNBL3
 273
 274    * Create Router: Post dataes for create Router and check it in ONOS
 275    * Update Router: Update the Router and compare it in ONOS
 276    * Delete Router: Delete the Router dataes and check it in ONOS
 277    * Create RouterInterface: Post RouterInterface data to an exist Router
 278      and check it in ONOS
 279    * Delete RouterInterface: Delete the RouterInterface and check the Router
 280    * Create FloatingIp: Post dataes for create FloatingIp and check it in
 281      ONOS
 282    * Update FloatingIp: Update the FloatingIp and compare it in ONOS
 283    * Delete FloatingIp: Delete the FloatingIp and check if it's NULL in
 284      ONOS  or not
 285    * Create External Gateway: Post dataes for create External Gateway to an
 286      exit Router and check it
 287    * Update External Gateway: Update the External Gateway and compare it
 288    * Delete External Gateway: Delete the External Gateway and check if it's
 289      NULL in ONOS or not
 290
 291
 292 Features
 293 --------
 294
 295 vIMS
 296 ^^^^
 297 The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
 298 architectural framework for delivering IP multimedia services.
 299
 300 vIMS has been integrated in Functest to demonstrate the capability to deploy a
 301 relatively complex NFV scenario on the OPNFV platform. The deployment of a complete
 302 functional VNF allows the test of most of the
 303 essential functions needed for a NFV platform.
 304
 305 The goal of this test suite consists of:
 306
 307  * deploy a VNF orchestrator (Cloudify)
 308  * deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF from this
 309    orchestrator based on a TOSCA blueprint defined in `[5]`_
 310  * run suite of signaling tests on top of this VNF
 311
 312 The Clearwater architecture is described as follows:
 313
 314 .. figure:: ../images/clearwater-architecture.png
 315    :align: center
 316    :alt: vIMS architecture
 317
 318
 319
 320 Promise
 321 ^^^^^^^
 322
 323 Promise provides a basic set of test cases as part of Brahmaputra.
 324
 325 The available 33 test cases can be grouped into 7 test suites:
 326
 327     #. Add a new OpenStack provider into resource pool: Registers
 328        OpenStack into a new resource pool and adds more capacity associated
 329        with this pool.
 330
 331     #. Allocation without reservation: Creates a new server in OpenStack
 332        and adds a new allocation record in Promise shim-layer.
 333
 334     #. Allocation using reservation for immediate use: Creates a resource
 335        reservation record with no start/end time and immediately creates a new
 336        server in OpenStack and add a new allocation record in Promise
 337        shim-layer.
 338
 339     #. Reservation for future use: Creates a resource reservation record
 340        for a future start time, queries, modifies and cancels the newly created
 341        reservation.
 342
 343     #. Capacity planning: Decreases and increases the available capacity
 344        from a provider in the future and queries the available collections and
 345        utilizations.
 346
 347     #. Reservation with conflict: Tries to create reservations for
 348        immediate and future use with conflict.
 349
 350     #. Cleanup test allocations: Destroys all allocations in OpenStack.
 351
 352
 353 SDNVPN
 354 ^^^^^^
 355 Many telecom network functions are relying on layer-3 infrastructure services,
 356 within a VNF between components, or towards existing external networks.
 357 In many cases, these external networks are implemented in MPLS/BGP technology in
 358 existing service provider wide-area-networks (WAN). This proven technology
 359 provides a good mechanism for inter-operation of a NFV Infrastructure (NFVI)
 360 and WAN.
 361
 362 The SDNVPN project defined a bgpvpn suite.
 363 This bgpvpn suite deals with 2 Tempest cases dedicated to the test of the
 364 OpenStack bgpvpn API:
 365
 366   * test_create_bgpvpn
 367   * test_create_bgpvpn_as_non_admin_fail
 368
 369 .. include:: ./runfunctest.rst
 370
 371 Test results
 372 ============
 373
 374 For Brahmaputra test results, see the functest results document at `[12]`_
 375
 376 Note that the results are documented per scenario basis. Although most of the test
 377 cases might show the same output, some of them are not supported by
 378 certain scenario. Please select the appropriate scenario and compare the results
 379 to the referenced in the documentation.
 380
 381
 382 Test Dashboard
 383 ==============
 384
 385 Based on results collected in CI, a test dashboard is dynamically generated.
 386
 387
 388 .. include:: ./troubleshooting.rst
 389
 390
 391 References
 392 ==========
 393
 394 .. _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/#functional-testing-installation
 395 .. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
 396 .. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
 397 .. _`[4]`: http://events.linuxfoundation.org/sites/events/files/slides/Functest%20in%20Depth_0.pdf
 398 .. _`[5]`: https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/blob/master/openstack-blueprint.yaml
 399 .. _`[6]`: https://wiki.opnfv.org/opnfv_test_dashboard
 400 .. _`[7]`: http://testresults.opnfv.org/testapi/test_projects/functest/cases
 401 .. _`[8]`: https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
 402 .. _`[9]`: https://git.opnfv.org/cgit/functest/tree/testcases/VIM/OpenStack/CI/libraries/os_defaults.yaml
 403 .. _`[10]`: https://git.opnfv.org/cgit/functest/tree/testcases/VIM/OpenStack/CI/rally_cert/task.yaml
 404 .. _`[11]`: http://robotframework.org/
 405 .. _`[12]`: http://artifacts.opnfv.org/functest/brahmaputra/docs/results/index.html
 406
 407 OPNFV main site: opnfvmain_.
 408
 409 OPNFV functional test page: opnfvfunctest_.
 410
 411 IRC support chan: #opnfv-testperf
 412
 413 .. _opnfvmain: http://www.opnfv.org
 414 .. _opnfvfunctest: https://wiki.opnfv.org/opnfv_functional_testing
 415 .. _`OpenRC`: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html
 416 .. _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
 417 .. _`config_test.py` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.py
 418 .. _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml