docs/testing/user/userguide/index.rst

   1 .. _functest-userguide:
   2
   3 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   4 .. SPDX-License-Identifier: CC-BY-4.0
   5
   6 =========================
   7 OPNFV FUNCTEST user guide
   8 =========================
   9
  10 .. toctree::
  11    :maxdepth: 2
  12
  13 Version history
  14 ===============
  15 +------------+----------+------------------+----------------------------------+
  16 | **Date**   | **Ver.** | **Author**       | **Comment**                      |
  17 |            |          |                  |                                  |
  18 +------------+----------+------------------+----------------------------------+
  19 | 2016-08-17 | 1.0.0    | Juha Haapavirta  | Colorado release                 |
  20 |            |          | Column Gaynor    |                                  |
  21 +------------+----------+------------------+----------------------------------+
  22 | 2017-01-23 | 1.0.1    | Morgan Richomme  | Adaptations for Danube           |
  23 |            |          |                  |                                  |
  24 |            |          |                  |                                  |
  25 +------------+----------+------------------+----------------------------------+
  26
  27
  28 Introduction
  29 ============
  30
  31 The goal of this document is to describe the OPNFV Functest test cases and to
  32 provide a procedure to execute them. In the OPNFV Danube system release,
  33 a Functest CLI utility is introduced for an easier execution of test procedures.
  34
  35 **IMPORTANT**: It is assumed here that the Functest Docker container is already
  36 properly deployed and that all instructions described in this guide are to be
  37 performed from *inside* the deployed Functest Docker container.
  38
  39 .. include:: ./introduction.rst
  40
  41 The different test cases are described in the remaining sections of this document.
  42
  43 VIM (Virtualized Infrastructure Manager)
  44 ----------------------------------------
  45
  46 Healthcheck tests
  47 ^^^^^^^^^^^^^^^^^
  48 In Danube, healthcheck tests have been refactored and rely on SNAPS, a
  49 OPNFV middleware project.
  50
  51 SNAPS stands for "SDN/NFV Application development Platform and Stack".
  52 SNAPS is an object-oriented OpenStack library packaged with tests that exercise
  53 OpenStack.
  54 More information on SNAPS can be found in  `[13]`_
  55
  56 Three tests are declared as healthcheck tests and can be used for gating by the
  57 installer, they cover functionally the tests previously done by healthcheck
  58 test case.
  59
  60 The tests are:
  61
  62
  63  * *connection_check*
  64  * *api_check*
  65  * *snaps_health_check*
  66
  67 Connection_check consists in 9 test cases (test duration < 5s) checking the
  68 connectivity with Glance, Keystone, Neutron, Nova and the external network.
  69
  70 Api_check verifies the retrieval of OpenStack clients: Keystone, Glance,
  71 Neutron and Nova and may perform some simple queries. When the config value of
  72 snaps.use_keystone is True, functest must have access to the cloud's private
  73 network. This suite consists in 49 tests (test duration < 2 minutes).
  74
  75 snaps_health_check creates instance, allocate floating IP, connect to the VM.
  76 This test replaced the previous Colorado healthcheck test.
  77
  78 Self-obviously, successful completion of the 'healthcheck' testcase is a
  79 necessary pre-requisite for the execution of all other test Tiers.
  80
  81
  82 vPing_ssh
  83 ^^^^^^^^^
  84
  85 Given the script **ping.sh**::
  86
  87     #!/bin/sh
  88     while true; do
  89         ping -c 1 $1 2>&1 >/dev/null
  90         RES=$?
  91         if [ "Z$RES" = "Z0" ] ; then
  92             echo 'vPing OK'
  93             break
  94         else
  95             echo 'vPing KO'
  96         fi
  97     sleep 1
  98     done
  99
 100
 101 The goal of this test is to establish an SSH connection using a floating IP
 102 on the Public/External network and verify that 2 instances can talk over a Private
 103 Tenant network::
 104
 105  vPing_ssh test case
 106  +-------------+                    +-------------+
 107  |             |                    |             |
 108  |             | Boot VM1 with IP1  |             |
 109  |             +------------------->|             |
 110  |   Tester    |                    |   System    |
 111  |             | Boot VM2           |    Under    |
 112  |             +------------------->|     Test    |
 113  |             |                    |             |
 114  |             | Create floating IP |             |
 115  |             +------------------->|             |
 116  |             |                    |             |
 117  |             | Assign floating IP |             |
 118  |             | to VM2             |             |
 119  |             +------------------->|             |
 120  |             |                    |             |
 121  |             | Establish SSH      |             |
 122  |             | connection to VM2  |             |
 123  |             | through floating IP|             |
 124  |             +------------------->|             |
 125  |             |                    |             |
 126  |             | SCP ping.sh to VM2 |             |
 127  |             +------------------->|             |
 128  |             |                    |             |
 129  |             | VM2 executes       |             |
 130  |             | ping.sh to VM1     |             |
 131  |             +------------------->|             |
 132  |             |                    |             |
 133  |             |    If ping:        |             |
 134  |             |      exit OK       |             |
 135  |             |    else (timeout): |             |
 136  |             |      exit Failed   |             |
 137  |             |                    |             |
 138  +-------------+                    +-------------+
 139
 140 This test can be considered as an "Hello World" example.
 141 It is the first basic use case which **must** work on any deployment.
 142
 143 vPing_userdata
 144 ^^^^^^^^^^^^^^
 145
 146 This test case is similar to vPing_ssh but without the use of Floating IPs
 147 and the Public/External network to transfer the ping script.
 148 Instead, it uses Nova metadata service to pass it to the instance at booting time.
 149 As vPing_ssh, it checks that 2 instances can talk to
 150 each other on a Private Tenant network::
 151
 152  vPing_userdata test case
 153  +-------------+                    +-------------+
 154  |             |                    |             |
 155  |             | Boot VM1 with IP1  |             |
 156  |             +------------------->|             |
 157  |             |                    |             |
 158  |             | Boot VM2 with      |             |
 159  |             | ping.sh as userdata|             |
 160  |             | with IP1 as $1.    |             |
 161  |             +------------------->|             |
 162  |   Tester    |                    |   System    |
 163  |             | VM2 exeutes ping.sh|    Under    |
 164  |             | (ping IP1)         |     Test    |
 165  |             +------------------->|             |
 166  |             |                    |             |
 167  |             | Monitor nova       |             |
 168  |             |  console-log VM 2  |             |
 169  |             |    If ping:        |             |
 170  |             |      exit OK       |             |
 171  |             |    else (timeout)  |             |
 172  |             |      exit Failed   |             |
 173  |             |                    |             |
 174  +-------------+                    +-------------+
 175
 176 When the second VM boots it will execute the script passed as userdata
 177 automatically. The ping will be detected by periodically capturing the output
 178 in the console-log of the second VM.
 179
 180
 181 Tempest
 182 ^^^^^^^
 183
 184 Tempest `[2]`_ is the reference OpenStack Integration test suite.
 185 It is a set of integration tests to be run against a live OpenStack cluster.
 186 Tempest has suites of tests for:
 187
 188   * OpenStack API validation
 189   * Scenarios
 190   * Other specific tests useful in validating an OpenStack deployment
 191
 192 Functest uses Rally `[3]`_ to run the Tempest suite.
 193 Rally generates automatically the Tempest configuration file **tempest.conf**.
 194 Before running the actual test cases,
 195 Functest creates the needed resources (user, tenant) and
 196 updates the appropriate parameters into the configuration file.
 197
 198 When the Tempest suite is executed, each test duration is measured and the full
 199 console output is stored to a *log* file for further analysis.
 200
 201 The Tempest testcases are distributed across two
 202 Tiers:
 203
 204   * Smoke Tier - Test Case 'tempest_smoke_serial'
 205   * Components Tier - Test case 'tempest_full_parallel'
 206
 207 NOTE: Test case 'tempest_smoke_serial' executes a defined set of tempest smoke
 208 tests with a single thread (i.e. serial mode). Test case 'tempest_full_parallel'
 209 executes all defined Tempest tests using several concurrent threads
 210 (i.e. parallel mode). The number of threads activated corresponds to the number
 211 of available logical CPUs.
 212
 213 The goal of the Tempest test suite is to check the basic functionalities of the
 214 different OpenStack components on an OPNFV fresh installation, using the
 215 corresponding REST API interfaces.
 216
 217
 218 Rally bench test suites
 219 ^^^^^^^^^^^^^^^^^^^^^^^
 220
 221 Rally `[3]`_ is a benchmarking tool that answers the question:
 222
 223 *How does OpenStack work at scale?*
 224
 225 The goal of this test suite is to benchmark all the different OpenStack modules and
 226 get significant figures that could help to define Telco Cloud KPIs.
 227
 228 The OPNFV Rally scenarios are based on the collection of the actual Rally scenarios:
 229
 230  * authenticate
 231  * cinder
 232  * glance
 233  * heat
 234  * keystone
 235  * neutron
 236  * nova
 237  * quotas
 238  * requests
 239
 240 A basic SLA (stop test on errors) has been implemented.
 241
 242 The Rally testcases are distributed across two Tiers:
 243
 244   * Smoke Tier - Test Case 'rally_sanity'
 245   * Components Tier - Test case 'rally_full'
 246
 247 NOTE: Test case 'rally_sanity' executes a limited number of Rally smoke test
 248 cases. Test case 'rally_full' executes the full defined set of Rally tests.
 249
 250
 251 Refstack-client to run Defcore testcases
 252 -----------------------------------------
 253
 254 Refstack-client `[8]`_ is a command line utility that allows you to
 255 execute Tempest test runs based on configurations you specify.
 256 It is the official tool to run Defcore `[9]`_ testcases,
 257 which focuses on testing interoperability between OpenStack clouds.
 258
 259 Refstack-client is integrated in Functest, consumed by Dovetail, which
 260 intends to define and provide a set of OPNFV related validation criteria
 261 that will provide input for the evaluation of the use of OPNFV trademarks.
 262 This progress is under the guideline of Compliance Verification Program(CVP).
 263
 264 Defcore testcases
 265 ^^^^^^^^^^^^^^^^^^
 266
 267 *Danube Release*
 268
 269 Set of DefCore tempest test cases not flagged and required.
 270 According to `[10]`_, some tests are still flagged due to outstanding bugs
 271 in the Tempest library, particularly tests that require SSH. Refstack developers
 272 are working on correcting these bugs upstream. Please note that although some tests
 273 are flagged because of bugs, there is still an expectation that the capabilities
 274 covered by the tests are available. It only contains Openstack core compute
 275 (no object storage). The approved guidelines (2016.08) are valid for Kilo,
 276 Liberty, Mitaka and Newton releases of OpenStack.
 277 The list can be generated using the Rest API from RefStack project:
 278 https://refstack.openstack.org/api/v1/guidelines/2016.08/tests?target=compute&type=required&alias=true&flag=false
 279
 280 Running methods
 281 ^^^^^^^^^^^^^^^
 282
 283 Two running methods are provided after refstack-client integrated into
 284 Functest, Functest command line and manually, respectively.
 285
 286 By default, for Defcore test cases run by Functest command line,
 287 are run followed with automatically generated
 288 configuration file, i.e., refstack_tempest.conf. In some circumstances,
 289 the automatic configuration file may not quite satisfied with the SUT,
 290 Functest also inherits the refstack-client command line and provides a way
 291 for users to set its configuration file according to its own SUT manually.
 292
 293 *command line*
 294
 295 Inside the Functest container, first to prepare Functest environment:
 296
 297 ::
 298
 299   functest env prepare
 300
 301 then to run default defcore testcases by using refstack-client:
 302
 303 ::
 304
 305   functest testcase run refstack_defcore
 306
 307 In OPNFV Continuous Integration(CI) system, the command line method is used.
 308
 309 *manually*
 310
 311 Inside the Functest container, first to prepare the refstack virtualenv:
 312
 313 ::
 314
 315   cd /home/opnfv/repos/refstack-client
 316   source .venv/bin/activate
 317
 318 then prepare the tempest configuration file and the testcases want to run with the SUT,
 319 run the testcases with:
 320
 321 ::
 322
 323   ./refstack-client test -c <Path of the tempest configuration file to use> -v --test-list <Path or URL of test list>
 324
 325 using help for more information:
 326
 327 ::
 328
 329   ./refstack-client --help
 330   ./refstack-client test --help
 331
 332 Reference tempest configuration
 333 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 334
 335 *command line method*
 336
 337 When command line method is used, the default tempest configuration file
 338 is generated by Rally.
 339
 340 *manually*
 341
 342 When running manually is used, recommended way to generate tempest configuration
 343 file is:
 344
 345 ::
 346
 347   cd /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/refstack_client
 348   python tempest_conf.py
 349
 350 a file called tempest.conf is stored in the current path by default, users can do
 351 some adjustment according to the SUT:
 352
 353 ::
 354
 355   vim refstack_tempest.conf
 356
 357 a reference article can be used `[15]`_.
 358
 359
 360 snaps_smoke
 361 ------------
 362
 363 This test case contains tests that setup and destroy environments with VMs with
 364 and without Floating IPs with a newly created user and project. Set the config
 365 value snaps.use_floating_ips (True|False) to toggle this functionality. When
 366 the config value of snaps.use_keystone is True, Functest must have access
 367 the cloud's private network.
 368 This suite consists in 38 tests (test duration < 10 minutes)
 369
 370
 371 SDN Controllers
 372 ---------------
 373
 374 There are currently 3 available controllers:
 375
 376  * OpenDaylight (ODL)
 377  * ONOS
 378  * OpenContrail (OCL)
 379
 380 OpenDaylight
 381 ^^^^^^^^^^^^
 382
 383 The OpenDaylight (ODL) test suite consists of a set of basic tests inherited
 384 from the ODL project using the Robot `[11]`_ framework.
 385 The suite verifies creation and deletion of networks, subnets and ports with
 386 OpenDaylight and Neutron.
 387
 388 The list of tests can be described as follows:
 389
 390  * Basic Restconf test cases
 391    * Connect to Restconf URL
 392    * Check the HTTP code status
 393
 394  * Neutron Reachability test cases
 395    * Get the complete list of neutron resources (networks, subnets, ports)
 396
 397  * Neutron Network test cases
 398    * Check OpenStack networks
 399    * Check OpenDaylight networks
 400    * Create a new network via OpenStack and check the HTTP status code returned by Neutron
 401    * Check that the network has also been successfully created in OpenDaylight
 402
 403  * Neutron Subnet test cases
 404    * Check OpenStack subnets
 405    * Check OpenDaylight subnets
 406    * Create a new subnet via OpenStack and check the HTTP status code returned by Neutron
 407    * Check that the subnet has also been successfully created in OpenDaylight
 408
 409  * Neutron Port test cases
 410    * Check OpenStack Neutron for known ports
 411    * Check OpenDaylight ports
 412    * Create a new port via OpenStack and check the HTTP status code returned by Neutron
 413    * Check that the new port has also been successfully created in OpenDaylight
 414
 415  * Delete operations
 416    * Delete the port previously created via OpenStack
 417    * Check that the port has been also successfully deleted in OpenDaylight
 418    * Delete previously subnet created via OpenStack
 419    * Check that the subnet has also been successfully deleted in OpenDaylight
 420    * Delete the network created via OpenStack
 421    * Check that the network has also been successfully deleted in OpenDaylight
 422
 423 Note: the checks in OpenDaylight are based on the returned HTTP status
 424 code returned by OpenDaylight.
 425
 426
 427 ONOS
 428 ^^^^
 429
 430 TestON Framework is used to test the ONOS SDN controller functions.
 431 The test cases deal with L2 and L3 functions.
 432 The ONOS test suite can be run on any ONOS compliant scenario.
 433
 434 The test cases are described as follows:
 435
 436  * onosfunctest: The main executable file contains the initialization of
 437    the docker environment and functions called by FUNCvirNetNB and
 438    FUNCvirNetNBL3
 439
 440  * FUNCvirNetNB
 441
 442    * Create Network: Post Network data and check it in ONOS
 443    * Update Network: Update the Network and compare it in ONOS
 444    * Delete Network: Delete the Network and check if it's NULL in ONOS or
 445      not
 446    * Create Subnet: Post Subnet data and check it in ONOS
 447    * Update Subnet: Update the Subnet and compare it in ONOS
 448    * Delete Subnet: Delete the Subnet and check if it's NULL in ONOS or not
 449    * Create Port: Post Port data and check it in ONOS
 450    * Update Port: Update the Port and compare it in ONOS
 451    * Delete Port: Delete the Port and check if it's NULL in ONOS or not
 452
 453  * FUNCvirNetNBL3
 454
 455    * Create Router: Post data for create Router and check it in ONOS
 456    * Update Router: Update the Router and compare it in ONOS
 457    * Delete Router: Delete the Router data and check it in ONOS
 458    * Create RouterInterface: Post Router Interface data to an existing Router
 459      and check it in ONOS
 460    * Delete RouterInterface: Delete the RouterInterface and check the Router
 461    * Create FloatingIp: Post data for create FloatingIp and check it in ONOS
 462    * Update FloatingIp: Update the FloatingIp and compare it in ONOS
 463    * Delete FloatingIp: Delete the FloatingIp and check that it is 'NULL' in
 464      ONOS
 465    * Create External Gateway: Post data to create an External Gateway for an
 466      existing Router and check it in ONOS
 467    * Update External Gateway: Update the External Gateway and compare the change
 468    * Delete External Gateway: Delete the External Gateway and check that it is
 469      'NULL' in ONOS
 470
 471
 472 Features
 473 --------
 474
 475 In Danube, Functest supports the integration of:
 476
 477  * barometer
 478  * bgpvpn
 479  * doctor
 480  * domino
 481  * fds
 482  * multisite
 483  * odl-sfc
 484  * promise
 485  * security_scan
 486
 487 Please refer to the dedicated feature user guides for details.
 488
 489
 490 VNF
 491 ---
 492
 493
 494 cloudify_ims
 495 ^^^^^^^^^^^^
 496 The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
 497 architectural framework for delivering IP multimedia services.
 498
 499 vIMS has been integrated in Functest to demonstrate the capability to deploy a
 500 relatively complex NFV scenario on the OPNFV platform. The deployment of a complete
 501 functional VNF allows the test of most of the essential functions needed for a
 502 NFV platform.
 503
 504 The goal of this test suite consists of:
 505
 506  * deploy a VNF orchestrator (Cloudify)
 507  * deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF from this
 508    orchestrator based on a TOSCA blueprint defined in `[5]`_
 509  * run suite of signaling tests on top of this VNF
 510
 511 The Clearwater architecture is described as follows:
 512
 513 .. figure:: ../../../images/clearwater-architecture.png
 514    :align: center
 515    :alt: vIMS architecture
 516
 517 orchestra_ims
 518 ^^^^^^^^^^^^^
 519 Orchestra test case deals with the deployment of OpenIMS with OpenBaton
 520 orchestrator.
 521
 522 parser
 523 ^^^^^^
 524
 525 See parser user guide for details: `[12]`_
 526
 527
 528 vyos-vrouter
 529 ^^^^^^^^^^^^
 530
 531 This test case deals with the deployment and the test of vyos vrouter with
 532 Cloudify orchestrator. The test case can do testing for interchangeability of
 533 BGP Protocol using vyos.
 534
 535 The Workflow is as follows:
 536  * Deploy
 537     Deploy VNF Testing topology by Cloudify using blueprint.
 538  * Configuration
 539     Setting configuration to Target VNF and reference VNF using ssh
 540  * Run
 541     Execution of test command for test item written YAML format  file.
 542     Check VNF status and behavior.
 543  * Reporting
 544     Output of report based on result using JSON format.
 545
 546 The vyos-vrouter architecture is described in `[14]`_
 547
 548
 549
 550 .. include:: ./runfunctest.rst
 551
 552
 553 Test results
 554 ============
 555
 556 Manual testing
 557 --------------
 558
 559 In manual mode test results are displayed in the console and result files
 560 are put in /home/opnfv/functest/results.
 561
 562 Automated testing
 563 --------------
 564
 565 In automated mode, test results are displayed in jenkins logs, a summary is provided
 566 at the end of the job and can be described as follow::
 567
 568  +==================================================================================================================================================+
 569  |                                                                FUNCTEST REPORT                                                                   |
 570  +==================================================================================================================================================+
 571  |                                                                                                                                                  |
 572  |  Deployment description:                                                                                                                         |
 573  |    INSTALLER: fuel                                                                                                                               |
 574  |    SCENARIO:  os-odl_l2-nofeature-ha                                                                                                             |
 575  |    BUILD TAG: jenkins-functest-fuel-baremetal-daily-master-324                                                                                   |
 576  |    CI LOOP:   daily                                                                                                                              |
 577  |                                                                                                                                                  |
 578  +=========================+===============+============+===============+===========================================================================+
 579  | TEST CASE               | TIER          | DURATION   | RESULT        | URL                                                                       |
 580  +=========================+===============+============+===============+===========================================================================+
 581  | connection_check        | healthcheck   | 00:02      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb62b34079ac000a42e3fe |
 582  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 583  | api_check               | healthcheck   | 01:15      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb62fe4079ac000a42e3ff |
 584  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 585  | snaps_health_check      | healthcheck   | 00:50      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb63314079ac000a42e400 |
 586  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 587  | vping_ssh               | smoke         | 01:10      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb63654079ac000a42e401 |
 588  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 589  | vping_userdata          | smoke         | 00:59      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb63a14079ac000a42e403 |
 590  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 591  | tempest_smoke_serial    | smoke         | 12:57      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb66bd4079ac000a42e408 |
 592  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 593  | rally_sanity            | smoke         | 10:22      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb692b4079ac000a42e40a |
 594  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 595  | refstack_defcore        | smoke         | 12:28      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb6c184079ac000a42e40c |
 596  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 597  | snaps_smoke             | smoke         | 12:04      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb6eec4079ac000a42e40e |
 598  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 599  | domino                  | features      | 00:29      | PASS          | http://testresults.opnfv.org/test/api/v1/results/58cb6f044079ac000a42e40f |
 600  +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
 601
 602
 603 Results are automatically pushed to the test results database, some additional
 604 result files are pushed to OPNFV artifact web sites.
 605
 606 Based on the results stored in the result database, a `Functest reporting`_
 607 portal is also automatically updated. This portal provides information on:
 608
 609  * The overall status per scenario and per installer
 610  * Tempest: Tempest test case including reported errors per scenario and installer
 611  * vIMS: vIMS details per scenario and installer
 612
 613 .. figure:: ../../../images/functest-reporting-status.png
 614    :align: center
 615    :alt: Functest reporting portal Fuel status page
 616
 617 .. include:: ./troubleshooting.rst
 618
 619
 620 References
 621 ==========
 622
 623 .. _`[1]`: http://artifacts.opnfv.org/functest/colorado/docs/configguide/#
 624 .. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
 625 .. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
 626 .. _`[4]`: http://events.linuxfoundation.org/sites/events/files/slides/Functest%20in%20Depth_0.pdf
 627 .. _`[5]`: https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/blob/master/openstack-blueprint.yaml
 628 .. _`[6]`: https://scap.nist.gov/
 629 .. _`[7]`: https://github.com/OpenSCAP/openscap
 630 .. _`[8]`: https://github.com/openstack/refstack-client
 631 .. _`[9]`: https://github.com/openstack/defcore
 632 .. _`[10]`: https://github.com/openstack/interop/blob/master/2016.08/procedure.rst
 633 .. _`[11]`: http://robotframework.org/
 634 .. _`[12]`: http://artifacts.opnfv.org/parser/colorado/docs/userguide/index.html
 635 .. _`[13]`: https://wiki.opnfv.org/display/PROJ/SNAPS-OO
 636 .. _`[14]`: https://github.com/oolorg/opnfv-functest-vrouter
 637 .. _`[15]`: https://aptira.com/testing-openstack-tempest-part-1/
 638
 639 `OPNFV main site`_
 640
 641 `Functest page`_
 642
 643 IRC support chan: #opnfv-functest
 644
 645 .. _`OPNFV main site`: http://www.opnfv.org
 646 .. _`Functest page`: https://wiki.opnfv.org/functest
 647 .. _`OpenRC`: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html
 648 .. _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
 649 .. _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/functest/ci/config_functest.yaml
 650 .. _`Functest reporting`: http://testresults.opnfv.org/reporting/functest/release/danube/index-status-fuel.html