Modularity/BPO

The Build Pipeline Overview (BPO) component is a read-only user interface (UI) that will provide information about the build process of modules.

WHY

Information about module builds are scattered all over the place - in BPO, Koji, Bodhi, mirrormanager, ...

There should be one UI that would show you all the information needed.

WHAT

This page describes the first minimal version of BPO.

It will be focused on developers and release engineers. Later versions should be also focused on QA people, PMs, and end-users.

The first version should:

1. be ready* for flock
2. help people understand the whole concept
3. be subject to discussions, changes, extensions, ...

* Take this as a proposal by asamalik - it is nothing official or agreed at this moment. Ready would mean some initial hackish implementation that would help people to see the build process.

WHAT - the usability side

The first version will be focused on developers and release engineers with the following use-cases:

Developer:

• patches a package (component) for CVE, and wants to see:
  • which modules will be rebuilt
  • status of these rebuilds
• creates/updates a module (the yaml spec file) and wants to see:
  • a state of the build process of this module
  • a list of modules that depend on this one and will be rebuilt + status of these rebuilds

Rel-eng:

• a CVE has been patched in a package (component) and they want to see:
  • list of artifacts affected by this update
  • build states of modules from which are the artifacts composed
  • "all green" meaning everything has been rebuilt = CVE fixed everywhere, so they can make a press release about it

There will be other people with roles like QA, PM, end-users. Their use-cases will be covered in later versions of the BPO.

WHAT - the technical side

There will be three entities:

1. components (RPM package)
2. modules
3. artifacts (modular repo, iso, docker image)

And there would be three basic functions:

1. Search components, modules, and artifacts.
2. Browse 'relations' between components, modules, and artifacts.
3. See details of components, modules, and artifacts.

Details would be as follows:

1. Detail of a component
   • list of modules in which is this component included
   • build state of these modules
   • list of artifacts in which is this component included
2. Detail of a module
   • list of components included in this module
   • list of modules that are dependencies of this module
   • build state of these modules
   • list of modules that depend on this module
   • build state of these modules
   • list of artifacts that are composed with this module
3. Detail of an artifact
   • list of modules that are included in this artifact
   • their build states

Relationships

A module has the following relationships. The UI should allow to navigate trough these relationships to see details of other modules. It should also show the build states of all of these.

Build states

The build pipeline and corresponding build sates are shown on the picture below. The interface should show the state of a module in this pipeline.

HOW

The BPO will be composed of several microservices as shown on the following image:

There are three types of services:

• Updaters - these will fetch fedmsg messages or periodically query other services for data and update Elasticsearch.
• Elasticsearch - storage and search engine for data.
• User interfaces - web UI and API presenting data from Elasticsearch. These are read-only.

Data representation

Elasticsearch is a document database. A module or a module stack will be represented by a single document. All components will be part of the document, and all dependencies will be just links to other documents.