Standalone Scenario jobs

This section gives an overview and some details on the standalone scenario ci jobs. The standalone deployment is intended as a one node development environment for TripleO. - see the Standalone Deploy Guide for more information on setting up a standalone environment.

A ‘scenario’ is a concept used in TripleO to describe a collection of services - see the service-testing-matrix for more information about each scenario and the services deployed there. We combine the two to define the standalone scenario jobs.

These are intended to give developers faster feedback (the jobs are relatively fast to complete) and allow us to have better coverage across services by defining a number of scenarios. Crucially the standalone scenario jobs allow us to increase coverage without further increasing our resource usage footprint with eachjob only taking a single node. See this openstack-dev-thread for background around the move from the multinode jobs to the more resource friendly standalone versions.

Where

The standalone scenario jobs (hereafter referred to as just ‘standalone’ in this document), are defined in the tripleo-ci/zuul.d/standalone.yaml file. Besides the definitions for each of the scenario00X-standalone jobs, this file also carries the tripleo-standalone-scenarios-full_project-template which defines the zuul layout and files: sections for the standalone jobs in a central location.

Thus, the jobs are consumed by other projects across tripleo by inclusion of the template in their respective zuul layout file, for example tripleo-heat-templates and tripleo-common.

Besides the job definitions in the tripleo-ci repo, the other main part of the standalone jobs is a service environment file, which lives in the tripleo-heat-templates-ci/environments. As you can see in scenario001-env, scenario002-env, scenario003-env and scenario004-env that is where we define the services and parameters that are part of a given scenario.

How

The standalone jobs are special in that they differ from ‘traditional’ multinode jobs by having a shared featureset rather than requiring a dedicated featureset for each job. Some of the standalone scenarios, notably scenario012 will end up having a dedicated-featureset however in most cases the base standalone-featureset052 can be re-used for the different scenarios. Notably you can see that scenario001-job, scenario002-job, scenario003-job and scenario004-job job definitions are all using the same standalone-featureset052.

Given that we use the same featureset the main differentiator between these standalone jobs is the scenario environment file, which we pass using featureset_override (see How to add a TripleO job to your projects check pipeline). For example in the scenario001 job we point to the scenario001-standalone.yaml (scenario001-env):

- job:
    name: tripleo-ci-centos-7-scenario001-standalone
    voting: true
    parent: tripleo-ci-base-standalone
    nodeset: single-centos-7-node
    branches: ^(?!stable/(newton|ocata|pike|queens|rocky)).*$
    vars:
      featureset: '052'
      standalone_ceph: true
      featureset_override:
        standalone_container_cli: docker
        standalone_environment_files:
          - 'environments/low-memory-usage.yaml'
          - 'ci/environments/scenario001-standalone.yaml'
   ...

Finally we use a task in the tripleo-ci-run-test-role to pass the scenario environment file into the standalone deployment command using the standalone role standalone_custom_env_files parameter.