Update documentation for Danube
[functest.git] / docs / testing / user / userguide / introduction.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 Overview of the Functest suites
5 ===============================
6
7 Functest is the OPNFV project primarily targeting function testing.
8 In the Continuous Integration pipeline, it is launched after an OPNFV fresh
9 installation to validate and verify the basic functions of the
10 infrastructure.
11
12 The current list of test suites can be distributed over 5 main domains: VIM
13 (Virtualised Infrastructure Manager), Controllers (i.e. SDN Controllers),
14 Features, VNF (Virtual Network Functions) and MANO stacks.
15
16 Functest test suites are also distributed in the OPNFV testing categories:
17 healthcheck, smoke, features, components, performance, VNF, Stress tests.
18
19 All the Healthcheck and smoke tests of a given scenario must be succesful to
20 validate the scenario for the release.
21
22 +-------------+---------------+----------------+----------------------------------+
23 | Domain      | Tier          | Test case      | Comments                         |
24 +=============+===============+================+==================================+
25 | VIM         | healthcheck   | connection     | Check OpenStack connectivity     |
26 |             |               | _check         | through SNAPS framework          |
27 |             |               +----------------+----------------------------------+
28 |             |               | api_check      | Check OpenStack API through      |
29 |             |               |                | SNAPS framework                  |
30 |             |               +----------------+----------------------------------+
31 |             |               | snaps_health   |  basic instance creation, check  |
32 |             |               | \_check        |  DHCP                            |
33 |             +---------------+----------------+----------------------------------+
34 |             | smoke         | vping_ssh      | NFV "Hello World" using an SSH   |
35 |             |               |                | connection to a destination VM   |
36 |             |               |                | over a created floating IP       |
37 |             |               |                | address on the SUT Public /      |
38 |             |               |                | External network. Using the SSH  |
39 |             |               |                | connection a test script is then |
40 |             |               |                | copied to the destination        |
41 |             |               |                | VM and then executed via SSH.    |
42 |             |               |                | The script will ping another     |
43 |             |               |                | VM on a specified IP address over|
44 |             |               |                | the SUT Private Tenant network.  |
45 |             |               +----------------+----------------------------------+
46 |             |               | vping_userdata | Uses Ping with given userdata    |
47 |             |               |                | to test intra-VM connectivity    |
48 |             |               |                | over the SUT Private Tenant      |
49 |             |               |                | network. The correct operation   |
50 |             |               |                | of the NOVA Metadata service is  |
51 |             |               |                | also verified in this test.      |
52 |             |               +----------------+----------------------------------+
53 |             |               | tempest_smoke  | Generate and run a relevant      |
54 |             |               | \_serial       | Tempest Test Suite in smoke mode.|
55 |             |               |                | The generated test set is        |
56 |             |               |                | dependent on the OpenStack       |
57 |             |               |                | deployment environment.          |
58 |             |               +----------------+----------------------------------+
59 |             |               | rally_sanity   | Run a subset of the OpenStack    |
60 |             |               |                | Rally Test Suite in smoke mode   |
61 |             |               +----------------+----------------------------------+
62 |             |               | snaps_smoke    | Run a subset of the OpenStack    |
63 |             |               |                | Rally Test Suite in smoke mode   |
64 |             |               +----------------+----------------------------------+
65 |             |               | refstack       | Reference RefStack suite         |
66 |             |               |   \_defcore    | tempest selection for NFV        |
67 |             +---------------+----------------+----------------------------------+
68 |             | components    | tempest_full   | Generate and run a full set of   |
69 |             |               | \_parallel     | the OpenStack Tempest Test Suite.|
70 |             |               |                | See the OpenStack reference test |
71 |             |               |                | suite `[2]`_. The generated      |
72 |             |               |                | test set is dependent on the     |
73 |             |               |                | OpenStack deployment environment.|
74 |             |               +----------------+----------------------------------+
75 |             |               | rally_full     | Run the OpenStack testing tool   |
76 |             |               |                | benchmarking OpenStack modules   |
77 |             |               |                | See the Rally documents `[3]`_.  |
78 |             |               +----------------+----------------------------------+
79 |             |               | tempest_custom | Allow to run a customized list   |
80 |             |               |                | of Tempest cases                 |
81 +-------------+---------------+----------------+----------------------------------+
82 | Controllers | smoke         | odl            | Opendaylight Test suite          |
83 |             |               |                | Limited test suite to check the  |
84 |             |               |                | basic neutron (Layer 2)          |
85 |             |               |                | operations mainly based on       |
86 |             |               |                | upstream testcases. See below    |
87 |             |               |                | for details                      |
88 |             |               +----------------+----------------------------------+
89 |             |               | onos           | Test suite of ONOS L2 and L3     |
90 |             |               |                | functions.                       |
91 |             |               |                | See `ONOSFW User Guide`_  for    |
92 |             |               |                | details.                         |
93 |             |               +----------------+----------------------------------+
94 |             |               | odl_netvirt    | Test Suite for the OpenDaylight  |
95 |             |               |                | SDN Controller when the NetVirt  |
96 |             |               |                | features are installed. It       |
97 |             |               |                | integrates some test suites from |
98 |             |               |                | upstream using Robot as the test |
99 |             |               |                | framework                        |
100 |             |               +----------------+----------------------------------+
101 |             |               | fds            | Test Suite for the OpenDaylight  |
102 |             |               |                | SDN Controller when the GBP      |
103 |             |               |                | features are installed. It       |
104 |             |               |                | integrates some test suites from |
105 |             |               |                | upstream using Robot as the test |
106 |             |               |                | framework                        |
107 +-------------+---------------+----------------+----------------------------------+
108 | Features    | features      | bgpvpn         | Implementation of the OpenStack  |
109 |             |               |                | bgpvpn API from the SDNVPN       |
110 |             |               |                | feature project. It allows for   |
111 |             |               |                | the creation of BGP VPNs.        |
112 |             |               |                | See `SDNVPN User Guide`_ for     |
113 |             |               |                | details                          |
114 |             |               +----------------+----------------------------------+
115 |             |               | doctor         | Doctor platform, as of Colorado  |
116 |             |               |                | release, provides the three      |
117 |             |               |                | features:                        |
118 |             |               |                | * Immediate Notification         |
119 |             |               |                | * Consistent resource state      |
120 |             |               |                | awareness for compute host down  |
121 |             |               |                | * Valid compute host status      |
122 |             |               |                | given to VM owner                |
123 |             |               |                | See `Doctor User Guide`_ for     |
124 |             |               |                | details                          |
125 |             |               +----------------+----------------------------------+
126 |             |               | domino         | Domino provides TOSCA template   |
127 |             |               |                | distribution service for network |
128 |             |               |                | service and VNF descriptors      |
129 |             |               |                | among MANO components e.g.,      |
130 |             |               |                | NFVO, VNFM, VIM, SDN-C, etc.,    |
131 |             |               |                | as well as OSS/BSS functions.    |
132 |             |               |                | See `Domino User Guide`_ for     |
133 |             |               |                | details                          |
134 |             |               +----------------+----------------------------------+
135 |             |               | multisite      | Multisite                        |
136 |             |               |                | See `Multisite User Guide`_ for  |
137 |             |               |                | details                          |
138 |             |               +----------------+----------------------------------+
139 |             |               | netready       | Testing from netready project    |
140 |             |               |                | ping using gluon                 |
141 |             |               +----------------+----------------------------------+
142 |             |               | odl-sfc        | SFC testing for odl scenarios    |
143 |             |               |                | See `SFC User Guide`_ for details|
144 |             |               +----------------+----------------------------------+
145 |             |               | parser         | Parser is an integration project |
146 |             |               |                | which aims to provide            |
147 |             |               |                | placement/deployment templates   |
148 |             |               |                | translation for OPNFV platform,  |
149 |             |               |                | including TOSCA -> HOT, POLICY ->|
150 |             |               |                | TOSCA and YANG -> TOSCA. it      |
151 |             |               |                | deals with a fake vRNC.          |
152 |             |               |                | See `Parser User Guide`_ for     |
153 |             |               |                | details                          |
154 |             |               +----------------+----------------------------------+
155 |             |               | promise        | Resource reservation and         |
156 |             |               |                | management project to identify   |
157 |             |               |                | NFV related requirements and     |
158 |             |               |                | realize resource reservation for |
159 |             |               |                | future usage by capacity         |
160 |             |               |                | management of resource pools     |
161 |             |               |                | regarding compute, network and   |
162 |             |               |                | storage.                         |
163 |             |               |                | See `Promise User Guide`_ for    |
164 |             |               |                | details.                         |
165 |             |               +----------------+----------------------------------+
166 |             |               | security_scan  | Implementation of a simple       |
167 |             |               |                | security scan. (Currently        |
168 |             |               |                | available only for the Apex      |
169 |             |               |                | installer environment)           |
170 +-------------+---------------+----------------+----------------------------------+
171 | VNF         | vnf           | cloudify_ims   | Example of a real VNF deployment |
172 |             |               |                | to show the NFV capabilities of  |
173 |             |               |                | the platform. The IP Multimedia  |
174 |             |               |                | Subsytem is a typical Telco test |
175 |             |               |                | case, referenced by ETSI.        |
176 |             |               |                | It provides a fully functional   |
177 |             |               |                | VoIP System                      |
178 |             |               +----------------+----------------------------------+
179 |             |               | orchestra_ims  | OpenIMS deployment using         |
180 |             |               |                | Openbaton orchestrator           |
181 |             |               +----------------+----------------------------------+
182 |             |               | vyos_vrouter   | vRouter testing                  |
183 +-------------+---------------+----------------+----------------------------------+
184
185
186 As shown in the above table, Functest is structured into different 'domains',
187 'tiers' and 'test cases'. Each 'test case' usually represents an actual
188 'Test Suite' comprised -in turn- of several test cases internally.
189
190 Test cases also have an implicit execution order. For example, if the early
191 'healthcheck' Tier testcase fails, or if there are any failures in the 'smoke'
192 Tier testcases, there is little point to launch a full testcase execution round.
193
194 In Danube, we merged smoke and sdn controller tiers in smoke tier.
195
196 An overview of the Functest Structural Concept is depicted graphically below:
197
198 .. figure:: ../../../images/concepts_mapping_final.png
199    :align: center
200    :alt: Functest Concepts Structure
201
202 Some of the test cases are developed by Functest team members, whereas others
203 are integrated from upstream communities or other OPNFV projects. For example,
204 `Tempest <http://docs.openstack.org/developer/tempest/overview.html>`_ is the
205 OpenStack integration test suite and Functest is in charge of the selection,
206 integration and automation of those tests that fit suitably to OPNFV.
207
208 The Tempest test suite is the default OpenStack smoke test suite but no new test
209 cases have been created in OPNFV Functest.
210
211 The results produced by the tests run from CI are pushed and collected into a
212 NoSQL database. The goal is to populate the database with results from different
213 sources and scenarios and to show them on a `Functest Dashboard`_. A screenshot
214 of a live Functest Dashboard is shown below:
215
216 .. figure:: ../../../images/FunctestDashboardDanube.png
217    :align: center
218    :alt: Functest Dashboard
219
220
221 Basic components (VIM, SDN controllers) are tested through their own suites.
222 Feature projects also provide their own test suites with different ways of
223 running their tests.
224
225 The notion of domain has been introduced in the description of the test cases
226 stored in the Database.
227 This parameters as well as possible tags can be used for the Test case catalog.
228
229 vIMS test case was integrated to demonstrate the capability to deploy a
230 relatively complex NFV scenario on top of the OPNFV infrastructure.
231
232 Functest considers OPNFV as a black box. As of Danube release the OPNFV
233 offers a lot of potential combinations:
234
235   * 3 controllers (OpenDaylight, ONOS, OpenContrail)
236   * 4 installers (Apex, Compass, Fuel, Joid)
237
238 Most of the tests are runnable by any combination, but some tests might have
239 restrictions imposed by the utilized installers or due to the available
240 deployed features. The system uses the environment variables (INSTALLER_IP and
241 DEPLOY_SCENARIO) to automatically determine the valid test cases, for each given
242 environment.
243
244 A convenience Functest CLI utility is also available to simplify setting up the
245 Functest evironment, management of the OpenStack environment (e.g. resource
246 clean-up) and for executing tests.
247 The Functest CLI organised the testcase into logical Tiers, which contain in
248 turn one or more testcases. The CLI allows execution of a single specified
249 testcase, all test cases in a specified Tier, or the special case of execution
250 of **ALL** testcases. The Functest CLI is introduced in more detail in the
251 section `Executing the functest suites`_ of this document.
252
253 .. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
254 .. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
255 .. _`Copper User Guide`: http://artifacts.opnfv.org/copper/colorado/docs/userguide/index.html
256 .. _`Doctor User Guide`: http://artifacts.opnfv.org/doctor/colorado/userguide/index.html
257 .. _`Promise User Guide`: http://artifacts.opnfv.org/promise/colorado/docs/userguide/index.html
258 .. _`ONOSFW User Guide`: http://artifacts.opnfv.org/onosfw/colorado/userguide/index.html
259 .. _`SDNVPN User Guide`: http://artifacts.opnfv.org/sdnvpn/colorado/docs/userguide/index.html
260 .. _`Domino User Guide`: http://artifacts.opnfv.org/domino/docs/userguide-single/index.html
261 .. _`Parser User Guide`: http://artifacts.opnfv.org/parser/colorado/docs/userguide/index.html
262 .. _`Functest Dashboard`: http://testresults.opnfv.org/kibana_dashboards/
263 .. _`SFC User Guide`: http://artifacts.opnfv.org/sfc/colorado/userguide/index.html
264 .. _`Multisite User Guide`: http://artifacts.opnfv.org/multisite/docs/userguide/index.html