Gitiles
Code Review Sign In
gerrit.nordix.org / infra / swconfig / 46757d350f5222f6602e5d0dd7252373e7d214c2 / . / scenarios / onap-nofeature-noha / kubespray / playbooks
tree: 23f415615e8d97e65afc0ed38b01f79498bd78c9 [path history] [tgz]
  1. files/
  2. promote.yml
  3. README.md
scenarios/onap-nofeature-noha/kubespray/playbooks/README.md

Nordix ONAP Pipelines

Nordix has 2 pipelines to run ONAP deployment and testing.

  • Online Pipelines
  • Offline Pipelines

Nordix ONAP Online Pipelines

Nordix ONAP Online Pipelines run against the master and latest stable branches on a nightly basis to verify the quality of corresponding branches.

Online Pipelines pull latest of everything, container images, source code, and so on from corresponding ONAP systems, Nexus, Gerrit, and so on. Because of this, these pipelines might not succeed at all times due to possible issues with the upstream.

The outcome of ONAP Online Pipelines are

  • Catching upstream issues, filing bug reports, and getting them fixed as early as possible
  • Providing feedback to upstream ONAP project with regards the quality of ONAP on a regular basis
  • Promoting ONAP to Nordix ONAP Offline Pipelines for build, packaging, deployment, and for further promotion

Online pipelines consist of various stages as listed below.

  • deploy: ONAP is deployed using OOM on a Kubernetes cluster that gets deployed on OpenStack using Kubespray.
  • oom-hc: Deployed ONAP is tested using xtesting to validate k8s and oom.
  • onap-hc-{core|small|medium|full}: Deployed ONAP is tested using xtesting in various flavors; core, small, medium, and full. These flavors test the basic functionality of the services that are classified as core, small, medium, and full.
  • onap-hc-healthdist: Deployed ONAP is tested using xtesting healthdist test case.
  • promote: ONAP (the container images, the repo shas) gets promoted for consumption by offline deployment pipelines.

See ONAP Online Pipeline for Master branch as an example.

Nordix ONAP Offline Pipelines

Nordix ONAP Offline Pipelines run against the selected branches periodically to build, package, deploy, test, and promote ONAP packages for further consumption in a closed environment.

The metadata/input used by Offline Pipelines is promoted/provided by Online Pipelines so what is taken and used by Offline Pipelines is properly tested rather than choosing artifacts randomly from upstream systems.

Nordix ONAP Promotion Mechanism

ONAP Offline Installer project comes with various tools, scripts, and Ansible playbooks to enable packaging, build, and deployment of ONAP in an offline fashion.

However, the way the artifacts (container images, source code) that are pulled in and built/packaged does not really follow the best practices as latest of everything gets pulled in from ONAP systems randomly. This may potentially cause issues later on when one attempts to deploy ONAP using the artifacts produced by using the untested versions of upstream artifacts.

In order to ensure what gets packaged, deployed, and tested has the basic quality, the starting point of Offline Pipelines are adjusted accordingly.

The playbook promote.yml and the scripts used by the playbook ensures that offline pipelines has the metadata regarding which artifacts to package, and use for deployment.

This is achieved by following below steps.

  • Once ONAP deployment and testing phases are completed in Online Pipelines, promotion phase starts running.
  • The first thing that's done during the promotion phase is the collection of ONAP docker container images from Kubernetes worker nodes so we can promote what actually got pulled in to worker nodes for deployment purposes by OOM. This is done by docker save commands on the worker nodes and resulting tarfiles are rsynched back to localhost.
  • Once all the tarfiles are rsynched to the localhost, they are imported as docker containers using docker load command.
  • After the completion of docker load, all the images are tagged with the orginal tags coming from upstream and also with the branch tags to be pushed to Nordix Harbor Container Image registry.
  • Container images get pushed to Nordix Harbor Container Image registry.
  • In order to ensure the consistency, traceability and reproducibility, repository digest of the container images that are pushed to Nordix Harbor Container Image registry are recorded.
  • As the last step a file named onap_docker_images.list is generated with the needed metadata. This file contains Nordix promotion ID, SHAs of ONAP OOM, Integration, and Offline Installer repositories used during online pipelines and container image repositories, tags, and repo digests that are pushed to Nordix Harbor Container Image registry in order to ensure offline deployment pipelines can gather required artifacts in a consistent manner.

Please see the latest onap_docker_images.list as an example.

The promoted ONAP docker container images are pushed to onap project on Nordix Harbor Container Image registry.

The rest is performed by offline deployment pipelines.