About CTS

Compose Tracking Service is a small service storing specific metadata about each Pungi Compose. It provides a REST API to manipulate these metadata and sends UMB messages on every change of these metadata.

Scope

The Compose Tracking Service stores only metadata directly related to built compose. This for example includes:

  • The productmd.ComposeInfo metadata - basic information about the compose like its name, version, release, …

  • The promotion state - Information whether the compose is just a “periodic” compose, or if it has been promoted to “nightly”, “milestone-candidate” or “milestone”.

  • Compose tags - Tags describing the compose. For example, once the compose is removed from the storage, the “removed” tag can be applied. Or if compose is tested by QA, the “qa-passed” tag can be applied.

Examples of another metadata which might be in scope, but are not planned to be included right now are:

  • List of compose deliverables - List of RPM builds included in a compose, list of container images included in a compose, …

  • List of compose Variants, architectures, …

The REST API provided by the Compose Tracking Service is focused only on metadata listed above.

The service might provide more advanced API calls working with these metadata, for example listing all composes containing particular RPM build, but these advanced API calls are not planned now. They would however be in scope for this service if needed in the future.

Not in scope

Metadata generated by external services:

The Compose Tracking Service is focused directly on the Compose. It will not collect or store additional metadata generated by other services. For example, the Compose Tracking Service will not provide any API to access complete test results for particular compose (These are stored for example in ResultsDB), or list of policies driving the compose promotion (These are stored in Greenwave).

Web user interface for end-users:

The Compose Tracking Service is not an end-user facing application. It is only storing compose metadata which can be used by other services and drive the RHEL promotion and testing process.

Main Goals

Ensure the compose ID is always unique, independent on the tool building the compose:

Each compose has a compose ID which uniquely identifies it. There is currently no policy which enforces it. There are multiple service building composes (ODCS, Pungi, …) and even within a single service, there are many compose configuration files.

With the compose promotion, the need to ensure the compose has always a unique compose ID is even bigger, because we need to be really sure that we are promoting the right compose and nobody can ever build the compose with the same compose ID.

Drive the promotion process:

We need to know the current state of the compose. Has it been promoted to “nightly”, “milestone-candidate” or is it just “periodic” compose? We need to be able to say to the releng team that we request promotion of particular compose. This needs to work in an automated and trackable way - for example, promote best periodic compose to nightly compose every night.

Allow testing the compose on state change:

We want to test composes early in the process. It would be ideal to test every compose we build, but not all tests can be run in an automated way on every compose. We therefore need to allow QE teams to choose which tests should be run and when.

For example, some tests can be executed for every “periodic” compose. Some tests make sense only once the compose is promoted to “nightly” compose.

The QE teams need a mechanism to be informed about the compose promotion.

Allow chain-tests by tagging composes:

QE teams often test composes in a chained way - one team finishes the testing and if the testing is successful, another team starts the testing. There is currently no standardized way how to synchronize these teams and how to see if particular compose passed important tests like “installability”.

Drive the compose removal process:

When compose data is removed from the storage, the external services pointing to this data need to be informed about this removal.

This is needed for example when Nightly compose is removed automatically from the /mnt/koji, because it was not promoted to milestone-candidate. Such compose needs to be removed also from other services referencing them.

Tracking location of the compose:

During the promotion process, the compose is often moved from one directory to another within the /mnt/koji. There needs to be a way to always get a correct and up-to-date URL (or path) to the content.

Allow querying for compose metadata:

The service needs to allow other services and users to filter and query for compose metadata.