docs/onap-integration-ci.rst

   1 .. _onap-integration-ci:
   2
   3 Integration Continuous Integration Guide
   4 ----------------------------------------
   5
   6 Continuous Integration is key due to the complexity of the ONAP projects.
   7 Several chains have been created:
   8
   9 - Daily stable chain
  10 - Daily master chain
  11 - Gating: On demand deployment of a full ONAP solution to validate patchsets
  12
  13 They are run on different environments (Orange labs, DT labs, Azure Cloud).
  14
  15 The following document will detail these chains and how you could set up such
  16 chains and/or provide test results to the community.
  17
  18 Integration CI Ecosystem
  19 ------------------------
  20
  21 Overview
  22 ~~~~~~~~
  23
  24 The global ecosystem can de described as follows:
  25
  26 .. figure:: files/CI/ONAP_CI_10.png
  27    :scale: 60 %
  28    :align: center
  29
  30 Several chains are run in ONAP.
  31 The CI chains are triggered from different CI systems (Jenkins or gitlab-ci) (1)
  32 on different target environments hosted on community labs (Windriver,
  33 Orange, DT, E///) or Azure clouds. Jobs (installation, tests) are executed on
  34 these labs (2). At the end, the results are pushed through the OPNFV test API (3)
  35 to a test database (4) hosted by Linux Foundation on
  36 http://testresults.opnfv.org.
  37 Results can be reported in different web pages hosted on LF or on gitlab.com (5).
  38
  39
  40 Daily Chains
  41 ~~~~~~~~~~~~
  42
  43 CI daily chains (Master and last Stable) are run on Orange, DT using gitlab-ci
  44 jobs and Ericsson using jenkins jobs.
  45
  46 Gating
  47 ~~~~~~
  48
  49 OOM gating has been introduced for El Alto. It consists of a deployment followed
  50 by a set of tests on patchsets submitted to OOM repository.
  51
  52 The CI part is managed on gitlab.com and the deployment is executed on ONAP
  53 Orange lab and Azure clouds.
  54 The goal is to provide a feedback - and ultimately to vote - on code change
  55 prior to merge to consolidate the OOM Master branch.
  56
  57 The developer can evaluate the consequences of his/her patchset on a fresh
  58 installation.
  59
  60 The gating is triggered in 2 scenarios:
  61
  62  - new patchset in OOM
  63  - comment with the magic word **oom_redeploy** is posted in the Gerrit's comment
  64    section
  65
  66 The procedure to submit new feature in CI is done in 3 steps as described in the
  67 figure below:
  68
  69 .. figure:: files/CI/3steps gating.png
  70    :scale: 100 %
  71    :align: center
  72
  73
  74 Visualization of the CI pipelines
  75 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  76
  77 As the CI chains are triggered from different systems, several web interfaces
  78 can be used to visualize them.
  79
  80 A web site has been created to centralize the links on http://testresults.opnfv.org/onap-integration/index.html
  81
  82 .. figure:: files/CI/ONAP_CI_3.png
  83    :scale: 60 %
  84    :align: center
  85
  86 For Gating and gitlab.com based CI chains, the pipelines consist in pipelines of
  87 pipelines managed through the chaining of .gitlab-ci.yml file thanks to an Open
  88 Source deployment called chained-ci (https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci).
  89 A visualization tool is available to list all your chains as described in the
  90 figure below:
  91
  92 .. figure:: files/CI/ONAP_CI_1.png
  93    :scale: 60 %
  94    :align: center
  95
  96 If you click on any element of the chain, you will open a new window:
  97
  98 .. figure:: files/CI/ONAP_CI_2.png
  99    :scale: 60 %
 100    :align: center
 101
 102 In order to provide the logs to the developer an additional web page has been
 103 created to summarize the tests and grant access to their associated logs:
 104
 105 .. figure:: files/CI/ONAP_CI_8.png
 106    :scale: 60 %
 107    :align: center
 108
 109 Additionnaly, for the daily chain, another page displays the results as time
 110 series, allowing to see the evolution of the tests over time.
 111
 112 .. figure:: files/CI/ONAP_CI_9.png
 113    :scale: 60 %
 114    :align: center
 115
 116
 117 Setup Your Own CI Chains
 118 ------------------------
 119
 120 If you want to setup a gitlab.com based CI chain, and want to use chained-ci,
 121 you can follow the tutorial on  https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci-handson
 122
 123 You should be able to chain your automation projects:
 124
 125 * Create resources
 126 * Deployment of Kubernetes
 127 * Test of your Kubernetes (using OPNFV functest-k8s tests)
 128 * Deployment of your ONAP (you can use your own automatic installation
 129   procedure or https://gitlab.com/Orange-OpenSource/lfn/onap/onap_oom_automatic_installation/)
 130 * Test ONAP thanks to the differnet ONAP xtesting dockers covering infrastructure
 131   healthcheck, components healthcheck tests, end to end tests, security tests.
 132
 133 If you want to report your results to the community, do not hesitate to contact
 134 the integration team. The Test database is public but the pods must be declared
 135 to be allowed to report results from third party labs.
 136
 137
 138 ONAP Integration Testing Gate
 139 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 140
 141 5 categories have been defined for the ONAP integration testing gate:
 142
 143 * infrastructure healthcheck: verify ONAP from a k8S perspective. It includes
 144   2 tests: onap-k8s (all the deployments, jobs, statefulste,..must be OK at
 145   the end of an installation), onap-helm (all the helm chart must be
 146   completed at the end of the installation)
 147 * healthcheck: the traditionnal robot tests run from the cluster to perform
 148   tests on the different components.
 149 * smoke-usecases: End to end tests
 150 * candidate-usecases: New end to end tests introduced in the automation chain
 151   for the release
 152 * security tests (security of kubernetes (CVE, CIS tests) and ONAP (exposed
 153   ports, check the containers run as root,...))
 154 * benchmarking (robustness, stress tests): not yet available
 155
 156 All these tests have been packaged thanks to the OPNFV Open Source tool xtesting.
 157 Xtesting is a python package allowing to unify the way to declare, run tests. It
 158 also ensures a consistent way to get the test results whatever the test framework
 159 used (python, robotframework, bash, ...). It includes the mechanism to
 160 automatically push the results to the test database using the test API.
 161 It simplifies the integration in CI.
 162
 163 The package can be found here https://pypi.org/project/xtesting/.
 164
 165 The different ONAP xtesting dockers can be found on https://gitlab.com/Orange-OpenSource/lfn/onap/integration/xtesting/container_registry
 166
 167 As an illustration, you can run the infrastructure healthcheck by typing the
 168 following command::
 169
 170     docker run -v <the kube config>:/root/.kube/config -v <result directory>:
 171     /var/lib/xtesting/results registry.gitlab.com/orange-opensource/lfn/onap/integration/xtesting/infra-healthcheck:latest
 172
 173 All the xtesting tests are included in Daily and gating chains.
 174 Please note that you can build your own onap-xtesting docker if you want to
 175 include your tests. See https://wiki.onap.org/pages/viewpage.action?pageId=79202765
 176 for details.