TripleO Dependency Pipeline¶

This section introduces the TripleO Dependency Pipeline. The dependency pipeline is what the TripleO CI team calls the series of zuul CI jobs that aim to catch problems in deployment dependencies.

A dependency is any package that is not directly related to the deployment of OpenStack itself, such as OpenvSwitch, podman, buildah, pacemaker and ansible. Each time, these projects release a newer version, it breaks the OpenStack deployment and CI.

Currently we have promotion and component pipeline set up to detect OpenStack projects related issues early.

In order to detect the breakages from non-openstack projects, TripleO dependency pipeline has come into existence. Currently we have a single type of pipeline enabled:

packages coming from specific repo

The configurations for each pipeline can be found under tripleo-quickstart/src/branch/master/config/release/dependency_ci/<module/repo name>/repo_config.yaml.

Current OpenStack Dependency Pipeline jobs¶

openstack-dependencies-openvswitch - for testing OVS and OVN dependencies coming from NFV sig repo.
openstack-dependencies-centos-compose - for testing jobs pinned to a specific CentOS compose build.

Note

The following pipelines were deprecated in favor of CentOS Stream 9 adoption:

openstack-dependencies-containertools - for testing container tools dependencies
openstack-dependencies-centos8stream - for testing base operating system dependencies coming from CentOS-8 stream repo.

Understanding Package Dependency Pipeline¶

openstack-dependencies-openvswitch is a package dependency pipeline where we tests OVS and OVN packages coming from NFV sig.

Here is the config for the openvswitch dependency pipeline:

add_repos:
  - type: generic
    reponame: openvswitch-next
    filename: "openvswitch-next.repo"
    baseurl: "https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/"
    update_container: false
dependency_override_repos:
  - centos-nfv-openvswitch,http://mirror.centos.org/centos/8/nfv/x86_64/openvswitch-2/
dep_repo_cmd_after: |
  {% if dependency_override_repos is defined %}
  {% for item in dependency_override_repos %}
  sudo dnf config-manager --set-disabled {{ item.split(',')[0] }}
  {% endfor %}
  sudo dnf clean metadata;
  sudo dnf clean all;
  sudo dnf update -y;
  {% endif %}

What do the above terms mean? * add_repos: This is the ‘test’ repo i.e. the one that is bringing us a newer than ‘normal’ version of the package we are testing, OpenvSwitch in this case. * dependency_override_repos: It is used to disable or override a particular repo.

In the above case, openvswitch-next.repo repo will get generated due to repo setup and will disables the centos-nfv-openvswitch repo.

Before the deployment, rdo-jobs/dependency/get-dependency-repo-content.yaml playbook is used to set particular release file (in this case it is config/release/dependency_ci/openvswitch/repo_config.yaml) and then generate a diff of packages from dependency_override_repos and new repos added by add_repos option.

Below are the jobs running in openstack-dependencies-openvswitch pipeline on review.rdoproject.org.

openstack-dependencies-openvswitch:
  jobs:
    - periodic-tripleo-ci-centos-8-standalone-openvswitch-container-build-master:
        dependencies:
          - periodic-tripleo-ci-centos-8-standalone-master
    - periodic-tripleo-ci-centos-8-scenario007-standalone-openvswitch-container-build-master:
        dependencies:
          - periodic-tripleo-ci-centos-8-scenario007-standalone-master
    - periodic-tripleo-ci-centos-8-standalone-master:
        vars:
          force_periodic: false
    - periodic-tripleo-ci-centos-8-scenario007-standalone-master:
        vars:
          force_periodic: false

Understanding CentOS Compose Pinning Dependency¶

The dependency compose-repos works in the same line as package dependency jobs, with the difference that instead of setting up a single repository at a time, it consumes metadata from the provided compose URL and generates a set of repos as specified in the configuration snippet below:

...
add_repos:
  - type: compose_repos
    compose_url: "https://odcs.stream.centos.org/production/latest-CentOS-Stream/compose/"
    release: centos-stream-9
    disable_conflicting: true
    variants:
      - AppStream
      - BaseOS
      - HighAvailability
      - CRB
    disable_repos:
      - quickstart-centos-appstreams.repo
      - quickstart-centos-base.repo
      - quickstart-centos-highavailability.repo
      - quickstart-centos-crb.repo

The compose_repos repo’s type was created to generate a set of repos based on a compose repos URL and information about variants and conflicting repos. The variants will define which repos should be created from compose metadata, while disable_conflicting and disable_repos should guarantee that conflicting repos will be disabled in favor of the new ones. For more details on how repos are generated, please check yum-config-compose in setup-role and yum-config tool.

Note

The process of setting up compose-repos starts earlier in the job, before any call to repo-setup, in one of the pre playbooks defined in base jobs. You shall see the centos-compose-repos.yml playbook running in jobs that have dependency set to centos-compose, which sets up those repos using the same tools mentioned above. The purpose of the dependency config here is to keep those repos enabled when any other playbook or role calls repo-setup.

Testing Jobs Using Compose Pinning Dependency¶

In order to test any job against a CentOS compose build, which can be a compose newer or older than the available on CentOS mirrors, you will need to setup a new job definition and provide the following job variables:

- job:
  name: tripleo-ci-centos-9-standalone-compose-pinning
  parent: tripleo-ci-centos-9-standalone
  vars:
    dependency: centos-compose
    centos_compose_url: https://odcs.stream.centos.org/production/latest-CentOS-Stream/compose/
    build_container_images: true
    containers_base_image: quay.io/centos/centos:stream9

dependency: need to be set to centos-compose.
centos_compose_url: CentOS compose URL to be tested. Note that the full URL ends with compose, because it is where compose metadata lives, required by yum-config tool to generate the repos. The default value is set to latest compose, which might be ahead of mirror’s compose.

Note

In the example above, there is an enabled flag for build_container_images. It means that process of building containers will also use compose repositories.

Ensuring Correct Module or Repo is Used¶

Once a jobs runs and finishes in the dependency pipeline, we need to navigate to job log url. Under logs/undercloud/home/zuul directory, we can see two log files:

control_repoquery_list.log.txt.gz - Contains a list of new packages coming from newly added repos.
control_test_diff_table.log.txt.gz - contains a diff of the packages coming from new repo and overridden repo

All the above operation is done rdo-jobs/playbooks/dependency/diff-control-test.yaml playbook which uses compare_rpms project from ci-config/ci-scripts/infra-setup/roles/rrcockpit/files.

Note

The dependency compose-repos doesn’t support rpm diff control test yet.

TripleO Dependency Pipeline

TripleO Dependency Pipeline¶

Current OpenStack Dependency Pipeline jobs¶

Understanding Package Dependency Pipeline¶

Understanding CentOS Compose Pinning Dependency¶

Testing Jobs Using Compose Pinning Dependency¶

Ensuring Correct Module or Repo is Used¶

TripleO 0.0.1.dev1691

Page Contents