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 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
  19 Testing
  20 -------
  21
  22 Test frameworks
  23 ~~~~~~~~~~~~~~~
  24
  25 Robotframework
  26 ..............
  27
  28 `robotframework <https://robotframework.org/>`_ is a well known test framework.
  29 Lots of ONAP tests are leveraging this framework.
  30 This framework is fully developed upstream even if some extensions (python
  31 modules) were created especially to deal with OpenStack (see
  32 `python-testing-utils project <https://git.onap.org/testsuite/python-testing-utils/>`_).
  33
  34 Some GUI tests (using Robotframework Selenium extension) had been initiated but
  35 not maintained, as a consequence there are not integrated in CI/CD.
  36
  37
  38 Python-onapsdk
  39 ..............
  40
  41 The Openstack and Kubernetes python SDK are references widely adopted by the
  42 developers and the industry. Developing a python ONAP SDK aimed to follow the
  43 examples of the infrastructure SDK with the same expectations in term of code
  44 quality.
  45 After an evaluation of the CLI project (JAVA SDK re-exposing primitives through
  46 python system calls), and a first prototype (onap_tests used until Frankfurt for
  47 end to end tests) it was decided to develop a new python SDK.
  48
  49 This SDK has been developed in gitlab.com to benefit from the numerous built-in
  50 options 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
  55 The project is fully Open Source, released under the Apache v2 license.
  56 Integration committers are invited to join the project. The main maintainers are
  57 ONAP integration and OOM committers.
  58
  59 Any 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
  69 A compagnon project has been created in ONAP:
  70 `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/>`_.
  71
  72 The pythonsdk-test project defines tests based on python-onapsdk.
  73
  74 The tests are hosted in this repository. They consume the different needed SDK:
  75 python-onapsdk but also the kubernetes, the OpenStack SDK and or any needed
  76 additional middlewares.
  77 The project developed the notion of steps that can been combined and reorganized
  78 as need to design a test. This project interacts with ONAP only through the
  79 python-onapsdk library.
  80 The tests are described in :ref:`The Integration Test page <integration-tests>`.
  81
  82 The 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
 106 You can reuse the existing steps to compose your test and/or code your own step
 107 if it is not supported yet.
 108
 109 The procedure to start a test is described in `pythonsdk-test README <https://git.onap.org/testsuite/pythonsdk-tests/tree/README.md>`_
 110
 111 Simulators
 112 ~~~~~~~~~~
 113
 114 Several 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
 121 pnf simulator
 122 .............
 123
 124 The `pnf-simulator <https://git.onap.org/integration/simulators/pnf-simulator/>`_
 125 can 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
 130 A Rest API has been integrated in Guilin, allowing a http control interface of
 131 the simulator.
 132
 133 See 'README.md <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=pnfsimulator/README.md;hb=43d113d683ab082f8e2b7ce062e9601e74ffde3a>'__
 134 for details.
 135
 136 Please 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>'__
 138 for 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
 146 CI/CD
 147 -----
 148
 149 The CI/CD is key for integration. It consolidates the trustability in the solution
 150 by the automated verification of the deployment and the execution of tests.
 151 Integration tests complete the component tests (unit and functional known as
 152 CSIT tests).
 153
 154 Xtesting
 155 ~~~~~~~~
 156
 157 As the tests can be very heterogeneous (framework, language, outputs), the
 158 integration team integrates the tests in simple isolated execution context based
 159 on docker called **xtesting dockers**.
 160
 161 Xtesting is a python library harmonizing the way to setup, run, teardown,
 162 manage the artifacts, manage the reporting of the tests (automatic push of the
 163 results on a DB backend). It was developed by
 164 `OPNFV functest project <https://git.opnfv.org/functest-xtesting/>`_.
 165 This python library is included in an alpine docker and contains the needed
 166 tests, their associated libraries as well as a testcases.yaml listing these tests.
 167 These docker files are built on any change in the integration/xtesting repository
 168 and daily to take into account the upstream changes.
 169
 170 The 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
 180 The configuration files are provided as volumes and defined in each docker.
 181 The use of this CI/CD abstraction for the tests simplify the integration
 182 of the test suites in any CI/CD systems and harmonize the inputs and the outputs.
 183
 184 The official documentation can be found on
 185 `xtesting official web site <https://xtesting.readthedocs.io/en/latest/>`_