[DOC] Update documentation with recent additions
[integration.git] / docs / integration-tooling.rst
1 .. This work is licensed under a
2    Creative Commons Attribution 4.0 International License.
3 .. integration-tooling:
4
5 Tooling
6 =======
7
8 .. important::
9    Integration team deals with lots of tools to complete its missions. The goal
10    of this section is to highlight some of them and redirect to their official
11    documentation. These tools can be used for CI/CD, Testing or platform management.
12
13    **Upstream tools** are privileged but when needed specific developments can be done.
14
15    Please note that none of these tools are imposed to test developers, in other
16    words, any kind of test is accepted and can be integrated, the list of tools
17    is just indicative.
18
19 Integration Project
20 -------------------
21
22 Integration portal
23 ..................
24
25 A portal is built to report the status of the different labs collaborating in
26 Integration, see http://testresults.opnfv.org/onap-integration/
27
28 .. figure:: files/CI/ONAP_CI_3.png
29    :align: center
30    :width: 6.5in
31
32 The code of this web site is shared on a public gitlab project.
33
34
35 Communication channels
36 ......................
37
38 The main communication channel for real time support is the official ONAP
39 Slack #integration-team chan (https://onapproject.slack.com/).
40
41 You can also send a mail to onap-discuss AT lists.onap.org
42 with [ONAP] [Integration] prefix in the title.
43
44 Repository management
45 .....................
46
47 Since Integration team manages few dozens of different repositories a tool was provided to aid the process of mass editing the INFO.yaml files. It can be found `here <https://git.onap.org/integration/tree/ptl/edit_committers_info>`__.
48
49 Testing
50 -------
51
52 Test frameworks
53 ~~~~~~~~~~~~~~~
54
55 Robotframework
56 ..............
57
58 `robotframework <https://robotframework.org/>`_ is a well known test framework.
59 Lots of ONAP tests are leveraging this framework.
60 This framework is fully developed upstream even if some extensions (python
61 modules) were created especially to deal with OpenStack (see
62 `python-testing-utils project <https://git.onap.org/testsuite/python-testing-utils/>`_).
63
64 Some GUI tests (using Robotframework Selenium extension) had been initiated but
65 not maintained, as a consequence they are not integrated in CI/CD.
66
67
68 Python-onapsdk
69 ..............
70
71 The Openstack and Kubernetes python SDK are references widely adopted by the
72 developers and the industry. Developing a python ONAP SDK aimed to follow the
73 examples of the infrastructure SDK with the same expectations in term of code
74 quality.
75 After an evaluation of the CLI project (JAVA SDK re-exposing primitives through
76 python system calls), and a first prototype (onap_tests used until Frankfurt for
77 end to end tests) it was decided to develop a new python SDK.
78
79 This SDK has been developed in gitlab.com to benefit from the numerous built-in
80 options offered by gitlab and ensure the best possible code quality.
81
82 - `python SDK repositoy <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`_
83 - `python SDK documentation <https://python-onapsdk.readthedocs.io/en/latest/?badge=develop>`_
84
85 The project is fully Open Source, released under the Apache v2 license.
86 Integration committers are invited to join the project. The main maintainers are
87 ONAP integration and OOM committers.
88
89 Any new feature shall respect the code quality criteria:
90
91 - unit test coverage > 98%
92 - functional tests (several components mock objects have been developed)
93
94 .. attention::
95     Python-onapsdk is a **SDK**, it means it is a tool allowing to communicate
96     with ONAP. It is a **middleware** that can be used by test projects but it is
97     **NOT a test**.
98
99 A compagnon project has been created in ONAP:
100 `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/>`_.
101
102 The pythonsdk-test project defines tests based on python-onapsdk.
103
104 The tests are hosted in this repository. They consume the different needed SDK:
105 python-onapsdk but also the kubernetes, the OpenStack SDK and or any needed
106 additional middlewares.
107 The project developed the notion of steps that can been combined and reorganized
108 as need to design a test. This project interacts with ONAP only through the
109 python-onapsdk library.
110 The tests are described in :ref:`The Integration Test page <integration-tests>`.
111
112 The available steps are:
113
114 - [CLAMP] OnboardClampStep: Onboard a SDC including a TCA blueprint
115 - [CDS] ExposeCDSBlueprintprocessorNodePortStep: expose CDS blueprint nodeport (Guilin workaround)
116 - [CDS] BootstrapBlueprintprocessor: Bootstrap a blueprint processor
117 - [CDS] DataDictionaryUploadStep: Upload a Data Dictionary to CDS
118 - [CDZ] CbaEnrichStep: Enrich CBA
119 - [K8S plugin] K8SProfileStep: Create K8S profile
120 - [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method
121 - [SO] YamlTemplateVlAlaCarteInstantiateStep: Instantiate network link described in YAML using SO a'la carte method.
122 - [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method
123 - [SO] YamlTemplateVnfAlaCarteInstantiateStep: Instantiate vnf described in YAML using SO a'la carte method
124 - [SO] YamlTemplateServiceAlaCarteInstantiateStep: Instantiate service described in YAML using SO a'la carte method
125 - [AAI] ConnectServiceSubToCloudRegionStep: Connect service subscription with cloud region
126 - [AAI] CustomerServiceSubscriptionCreateStep: Create customer's service subscription
127 - [AAI] CustomerCreateStep: Create customer
128 - [AAI] LinkCloudRegionToComplexStep: Connect cloud region with complex
129 - [AAI] ComplexCreateStep: Create complex
130 - [AAI] RegisterCloudRegionStep: Register cloud region
131 - [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file in SDC
132 - [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC
133 - [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC
134 - [SDC] VendorOnboardStep: Onboard vendor in SDC
135
136 You can reuse the existing steps to compose your test and/or code your own step
137 if it is not supported yet.
138
139 The procedure to start a test is described in `pythonsdk-test README <https://git.onap.org/testsuite/pythonsdk-tests/tree/README.md>`_
140
141 CI/CD
142 -----
143
144 The CI/CD is key for integration. It consolidates the trustability in the solution
145 by the automated verification of the deployment and the execution of tests.
146 Integration tests complete the component tests (unit and functional known as
147 CSIT tests).
148
149 Xtesting
150 ~~~~~~~~
151
152 As the tests can be very heterogeneous (framework, language, outputs), the
153 integration team integrates the tests in simple isolated execution context based
154 on docker called **xtesting dockers**.
155
156 Xtesting is a python library harmonizing the way to setup, run, teardown,
157 manage the artifacts, manage the reporting of the tests (automatic push of the
158 results on a DB backend). It was developed by
159 `OPNFV functest project <https://git.opnfv.org/functest-xtesting/>`_.
160 This python library is included in an alpine docker and contains the needed
161 tests, their associated libraries as well as a testcases.yaml listing these tests.
162 These docker files are built on any change in the integration/xtesting repository
163 and daily to take into account the upstream changes.
164
165 The integration project manages 5 xtesting dockers, see
166 :ref:`Integration Test page <integration-tests>`.
167
168 .. important::
169     **xtesting is a CI/CD framework, neither a test nor a test framework**
170
171     Testers can provide tests independently from xtesting.
172     However to be part of the CI/CD chains, an integration of the test in xtesting
173     will be required.
174
175 The configuration files are provided as volumes and defined in each docker.
176 The use of this CI/CD abstraction for the tests simplify the integration
177 of the test suites in any CI/CD systems and harmonize the inputs and the outputs.
178
179 The official documentation can be found on
180 `xtesting official web site <https://xtesting.readthedocs.io/en/latest/>`_
181
182 Integration Test database
183 ~~~~~~~~~~~~~~~~~~~~~~~~~
184
185 The integration team shares a Test Result Database with the OPNFV project. All
186 the test results of the CD are automatically pushed to this database.
187 It is possible to retrieve the results through the Test API associated with this
188 test Database.
189
190 The following information are available:
191
192 - List of pods allowed to push results: http://testresults.opnfv.org/onap/api/v1/pods
193 - List of projects that declared test cases for CI/CD: http://testresults.opnfv.org/onap/api/v1/projects
194 - List of integration test cases:
195   http://testresults.opnfv.org/onap/api/v1/projects/integration/cases
196 - List of security test cases:
197   http://testresults.opnfv.org/onap/api/v1/projects/security/cases
198 - Results with lots of possible filter combinations: http://testresults.opnfv.org/onap/api/v1/results?last=3
199
200 It is possible to get results according to several criteria (version, case name,
201 lab, period, last, CI id,..)
202 See the `OPNFV test API documentation <https://wiki.opnfv.org/pages/viewpage.action?pageId=2926452>`_.
203
204 Any company running ONAP Integration tests can be referenced to push their results
205 to this database.
206 This Database is hosted on a LF OPNFV server. Results are backuped daily.
207 Integration committers can have access to this server.
208
209 VNF demo Artifacts
210 ~~~~~~~~~~~~~~~~~~
211
212 VNF demo artifacts are hosted in the demo repositories and published in
213 https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf/.