blob: e69f990541d3dcd8c86225b5e7f60bf4793c0c27 [file] [log] [blame]
mrichomme7eecfb32020-11-26 15:24:27 +01001.. This work is licensed under a
2 Creative Commons Attribution 4.0 International License.
3.. integration-tooling:
4
5Tooling
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 priviledged 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
19Testing
20-------
21
22Test frameworks
23~~~~~~~~~~~~~~~
24
25Robotframework
26..............
27
28`robotframework <https://robotframework.org/>`_ is a well known test framework.
29Lots of ONAP tests are leveraging this framework.
30This framework is fully developed upstream even if some extensions (python
31modules) were created especially to deal with OpenStack (see
32`python-testing-utils project <https://git.onap.org/testsuite/python-testing-utils/>`_).
33
34Some GUI tests (using Robotframework Selenium extension) had been initiated but
35not maintained, as a consequence there are not integrated in CI/CD.
36
37
38Python-onapsdk
39..............
40
41The Openstack and Kubernetes python SDK are references widely adopted by the
42developers and the industry. Developing a python ONAP SDK aimed to follow the
43examples of the infrastructure SDK with the same expectations in term of code
44quality.
45After an evaluation of the CLI project (JAVA SDK re-exposing primitives through
46python system calls), and a first prototype (onap_tests used until Frankfurt for
47end to end tests) it was decided to develop a new python SDK.
48
49This SDK has been developed in gitlab.com to benefit from the numerous built-in
50options offered by gitlab and ensure the best possible code quality.
51
52- `python SDK repositoy <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`_
53- `python SDK documentation <https://python-onapsdk.readthedocs.io/en/latest/?badge=develop>`_
54
55The project is fully Open Source, released under the Apache v2 license.
56Integration committers are invited to join the project. The main maintainers are
57ONAP integration and OOM committers.
58
59Any new feature shall respect the code quality criteria:
60
61- unit test coverage > 98%
62- functional tests (several components mock objects have been developed)
63
64.. attention::
65 Python-onapsdk is a **SDK**, it means it is a tool allowing to communicate
66 with ONAP. It is a **middleware** that can be used by test projects but it is
67 **NOT a test**.
68
69A compagnon project has been created in ONAP:
70`pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/>`_.
71
72The pythonsdk-test project defines tests based on python-onapsdk.
73
74The tests are hosted in this repository. They consume the different needed SDK:
75python-onapsdk but also the kubernetes, the OpenStack SDK and or any needed
76additional middlewares.
77The project developed the notion of steps that can been combined and reorganized
78as need to design a test. This project interacts with ONAP only through the
79python-onapsdk library.
80The tests are described in :ref:`The Integration Test page <integration-tests>`.
81
82The available steps are:
83
84- [CLAMP] OnboardClampStep: Onboard a SDC including a TCA blueprint
85- [CDS] ExposeCDSBlueprintprocessorNodePortStep: expose CDS blueprint nodeport (Guilin workaround)
86- [CDS] BootstrapBlueprintprocessor: Bootstrap a blueprint processor
87- [CDS] DataDictionaryUploadStep: Upload a Data Dictionary to CDS
88- [CDZ] CbaEnrichStep: Enrich CBA
89- [K8S plugin] K8SProfileStep: Create K8S profile
90- [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method
91- [SO] YamlTemplateVlAlaCarteInstantiateStep: Instantiate network link described in YAML using SO a'la carte method.
92- [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method
93- [SO] YamlTemplateVnfAlaCarteInstantiateStep: Instantiate vnf described in YAML using SO a'la carte method
94- [SO] YamlTemplateServiceAlaCarteInstantiateStep: Instantiate service described in YAML using SO a'la carte method
95- [AAI] ConnectServiceSubToCloudRegionStep: Connect service subscription with cloud region
96- [AAI] CustomerServiceSubscriptionCreateStep: Create customer's service subscription
97- [AAI] CustomerCreateStep: Create customer
98- [AAI] LinkCloudRegionToComplexStep: Connect cloud region with complex
99- [AAI] ComplexCreateStep: Create complex
100- [AAI] RegisterCloudRegionStep: Register cloud region
101- [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file in SDC
102- [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC
103- [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC
104- [SDC] VendorOnboardStep: Onboard vendor in SDC
105
106You can reuse the existing steps to compose your test and/or code your own step
107if it is not supported yet.
108
109The procedure to start a test is described in `pythonsdk-test README <https://git.onap.org/testsuite/pythonsdk-tests/tree/README.md>`_
110
111Simulators
112~~~~~~~~~~
113
114Several simulators are created to support the use cases.
115
116.. important::
117 Before starting the development of a new simulator, please consider the existing
118 ones, you may fine a simulator that already partially fulfills your needs..
119 if so priviledge contributing to the simulator than creating a new one.
120
121pnf simulator
122.............
123
124The `pnf-simulator <https://git.onap.org/integration/simulators/pnf-simulator/>`_
125can be used for several tasks:
126
127- Simulate PNF and interact with CDS (reconfiguration, template update)
128- Send VES event to the VES collector and trigger closed loops
129
130A Rest API has been integrated in Guilin, allowing a http control interface of
131the simulator.
132
133See 'README.md <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=pnfsimulator/README.md;hb=43d113d683ab082f8e2b7ce062e9601e74ffde3a>'__
134for details.
135
136Please note that this simulator has optional python CLI, see
137'README.md <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=simulator-cli/README.md;hb=43d113d683ab082f8e2b7ce062e9601e74ffde3a>'__
138for details.
139
140.. note::
141 There are several pnf-simulators. This simulator is a legacy simulator. It
142 was forked and one of the fork is known as Mass PNF simulator (hosted in
143 integration repository).
144
145
146CI/CD
147-----
148
149The CI/CD is key for integration. It consolidates the trustability in the solution
150by the automated verification of the deployment and the execution of tests.
151Integration tests complete the component tests (unit and functional known as
152CSIT tests).
153
154Xtesting
155~~~~~~~~
156
157As the tests can be very heterogeneous (framework, language, outputs), the
158integration team integrates the tests in simple isolated execution context based
159on docker called **xtesting dockers**.
160
161Xtesting is a python library harmonizing the way to setup, run, teardown,
162manage the artifacts, manage the reporting of the tests (automatic push of the
163results on a DB backend). It was developed by
164`OPNFV functest project <https://git.opnfv.org/functest-xtesting/>`_.
165This python library is included in an alpine docker and contains the needed
166tests, their associated libraries as well as a testcases.yaml listing these tests.
167These docker files are built on any change in the integration/xtesting repository
168and daily to take into account the upstream changes.
169
170The integration project manages 5 xtesting dockers, see
171:ref:`Integration Test page <integration-tests>`.
172
173.. important::
174 **xtesting is a CI/CD framework, neither a test nor a test framework**
175
176 Testers can provide tests independently from xtesting.
177 However to be part of the CI/CD chains, an integration of the test in xtesting
178 will be required.
179
180The configuration files are provided as volumes and defined in each docker.
181The use of this CI/CD abstraction for the tests simplify the integration
182of the test suites in any CI/CD systems and harmonize the inputs and the outputs.
183
184The official documentation can be found on
185`xtesting official web site <https://xtesting.readthedocs.io/en/latest/>`_