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