The CI part provides the following features:
- Repository Verification (format of the INFO.yaml)
-- Patchset verification thank to json/yaml/python/go/rst/md linters. These jenkins
+- Patchset verification thank to json/yaml/python/go/rst/md linters. These Jenkins
verification jobs are hosted in the ci-management repository. They can vote
+1/-1 on patchset submission. Integration team systematically enables linters
on any new repository
Jenkins CD on Windriver/Intel lab
..................................
-The CD part on windriver/Intel is based on jenkins.
+The CD part on Windriver/Intel is based on Jenkins.
-It is based on a standalone VM hosting a jenkins server.
-The credentials of this VM as well as the jenkins server have been provided to
+It is based on a standalone VM hosting a Jenkins server.
+The credentials of this VM as well as the Jenkins server have been provided to
integration committers.
-Several jobs can be triggered from this jenkins interface.
+Several jobs can be triggered from this Jenkins interface.
Historically several chains were run daily (staging/release) but due to
performance issues, they have all been stopped.
Only SB-00 has been kept for use case support.
-The jenkins interface was however used to launch the installation of SB-00.
+The Jenkins interface was however used to launch the installation of SB-00.
-This jenkins script is leveraging resources available in OOM and integration
+This Jenkins script is leveraging resources available in OOM and integration
repositories.
-It was planned to replaced this CD by a gitlab runner based CD to unify the CD
-management. But due to performance issue in the DC it was not possible to
-finalize the operation in Guilin.
+The replacement of this CD by a gitlab runner based CD to unify the CD
+management was planned, but finalizing the operation in Guilin was not possible
+due to performance issues.
Gitlab CD
.........
- The Continuous Deployment (CD) Labs
- The Orange openlab
-Additionnaly integration contributors may deal with their own lab pushing results
+Additionally integration contributors may deal with their own lab pushing results
in the integration portal (See DT http://testresults.opnfv.org/onap-integration/dt/dt.html)
Windriver/Intel lab
In order to avoid disturbing the projects, the reinstallation has been postponed
after Guilin.
A huge cleanup has been done in order to save the resources.
-The historical CI/CD chains based on a stand alone jenkins VM hosted in Windriver
-have been stopped.For guilin only SB-00 has been kept and re-installed for the
+The historical CI/CD chains based on a stand-alone Jenkins VM hosted in Windriver
+have been stopped. For Guilin only SB-00 has been kept and re-installed for the
use case support.
If you want to use this lab, you need a VPN access. The procedure is described in
Environment Installation Scripts
................................
-In addition of the official OOM scripts, Integration used to provide some
-exwtra scripts/guidelines to install your OpenStack infrastructure thanks to a
+In addition to the official OOM scripts, Integration used to provide some
+extra scripts/guidelines to install your OpenStack infrastructure thanks to a
heat template. See :ref:`Integration heat guideline <integration-installation>`
-for details. This scripts were used mainly in windriver labs but are not actively
+for details. These scripts were used mainly in Windriver labs but are not actively
maintained.
.. caution:
Orange Openlab
--------------
-This lab is a community use lab. It is always provided the last stable version,
-so the frankfurt release during Guilin release time.
+This lab is for community use. It is always provided with the last stable version,
+i.e. Frankfurt release during Guilin development time.
Please note that such labs do not provide admin rights and is shared with all
the users. It can be used to discover ONAP.
-----------
The integration repository is the historical repository.
-As a consequence it includes several elements in the same reppository:
+As a consequence it includes several elements in the same repository:
- Deployment scripts (deployment directory)
- Tests: the first non robot tests (security, vCPE,..)
Testsuite
---------
-The testsuite repository and it sub repositories deal excelusively with tests.
+The testsuite repository and its sub repositories deal exclusively with tests.
The testsuite repository includes all the robotframework scripts.
-The robot pod that can be installed as part of the ONAP cluster is build from
+The robot pod that can be installed as part of the ONAP cluster is built from
this repository.
Several tooling repositories are associated with the robot tests (heatbridge,
External repositories
---------------------
-Additionnaly, the Integration team also deals with external gitlab.com
+Additionally, the Integration team also deals with external gitlab.com
repositories.
.. csv-table:: Integration external repositories table
:delim: ;
:header-rows: 1
-The python-onapsdk has been developped out of ONAP as gitlab provided more
-enhanced built-in features for this kind of developments.
+The python-onapsdk has been developed outside of ONAP as gitlab provided more
+enhanced built-in features for this kind of development.
The xtesting-onap repository is also hosted in gitlab.com as the CD part of
Integration work is based on public gitlab-ci chains.
-------------------------
The integration team shares a Test Result Database with the OPNFV project. All
-the test results of the CD are automatically pushed in this database.
+the test results of the CD are automatically pushed to this database.
It is possible to retrieve the results through the Test API associated with this
test Database.
See the `OPNFV test API documentation <https://wiki.opnfv.org/pages/viewpage.action?pageId=2926452>`__.
Any company running ONAP Integration tests can be referenced to push their results
-in this database.
+to this database.
This Database is hosted on a LF OPNFV server. Results are backuped daily.
Integration committers can have access to this server.
VNF demo Artifacts
------------------
-They are hosted in the demo repositories and published in
+VNF demo artifacts are hosted in the demo repositories and published in
https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf/.
Simulators
=====
.. important::
- Integration is in charged of several types of tests:
+ Integration is in charge of several types of tests:
- - Use Cases: developped by use case teams, usually complex, demonstrating high value capabilities ofr ONAP. They may be partially automated and even
+ - Use Cases: developed by use case teams, usually complex, demonstrating high value capabilities of ONAP. They may be partially automated and even
integrated in CD.
- CSIT Tests: functional tests created by the projects, partially hosted in CSIT repository
- - Automatic Test Cases: these use cases are usually more simple and aims to validate that ONAP is working properly.
+ - Automatic Test Cases: these use cases are usually more simple and aim to validate that ONAP is working properly.
These tests have been developed to validate ONAP as a software solution.
- In theory all the main function shall be covered by such tests in order to have more robust CI/CD and then avoid regressions.
+ In theory all the main functions shall be covered by such tests in order to have more robust CI/CD and then avoid regressions.
These tests are usually developed and maintained by the integration team.
-We may also indicate that when the development of the test framework python-onapsk
-follows standard developement quality rules and imposes the creation of
+We may also indicate that when the development of the test framework python-onapsdk
+follows standard development quality rules and imposes the creation of
unit/functional/integration tests.
As an example python-onapsdk requires a unit test coverage of 98% before merging
-a new feature, which is far above the project criteria in SonarCLoud today.
+a new feature, which is far above the project criteria in SonarCloud today.
Use Cases
---------
----------
The CSIT tests are functional tests executed by the projects on mocked
-environement to validate their components.
+environment to validate their components.
Historically it was hosted in a CSIT repository.
-Integration team invited the projects to bring back such tests bacdk to home
+Integration team invited the projects to bring back such tests back to home
repository for 2 main reasons:
- integration cannot be a bottleneck: +2/merge from integration needed for each
project
-- most of the tests are abandonned and not maintained when hosted in a third party
- repository leading to CI/CD time waste and misleading test reporting
+- most of the tests are abandoned and not maintained when hosted in a third party
+ repository leading to CI/CD resource waste and misleading test reporting
In Guilin a PoC to help the project to re-insource their functional tests have
been initiated.
.. hint::
Automatic tests are currently divided in 4 different categories:
- - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates,..
+ - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates...
- healthcheck: basic tests on components
- smoke tests: end to end tests
- security tests
.. figure:: files/tests/test-onap-k8s.png
-Healhcheck Tests
+Healthcheck Tests
................
.. csv-table:: Healthcheck Tests
Code Review / integration.git / commitdiff