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