Modularity/BPO: Difference between revisions

Revision as of 15:10, 10 July 2016

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:

be ready* for flock
help people understand the whole concept
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 and status of these rebuilds
creates/updates a module 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 and 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 the artifacts
- "all green" meaning everything has been rebuilt = CVE fixed everywhere, so they can make a press release about it

WHAT - the technical side

There will be three entities:

components (RPM package)
modules
artifacts (modular repo, iso, docker image)

And there would be three basic functions:

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

Details would as follows:

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

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

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

This is a question for the next sprint #10.

The BPO would be probably:

Read only. Web UI + API.

Database that would remember everything and will be updated by: - querying other components - listenning to fedmsg

@@ Line 1: / Line 1: @@
-The Build Pipeline Overview (BPO) component is a read-only user interface (UI) that will provide information about any module.
+The Build Pipeline Overview (BPO) component is a read-only user interface (UI) that will provide information about the build process of modules.
-The main three functions could be something like this:
+== WHY ==
-* Browsing and searching for modules
-* Showing build state of a module
-* Showing content of a module and relationships between modules
-== Browsing modules ==
+Information about module builds are scattered all over the place - in BPO, Koji, Bodhi, mirrormanager, ...
-Every module can be uniquely identified by the name of the module, version, and release (NVR). The interface should allow you to find a module based on NVR, show last version of a module, etc.
+There should be one UI that would show you all the information needed.
-== Build states ==
+== 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:
+# be ready* for flock
+# help people understand the whole concept
+# be subject to discussions, changes, extensions, ...
+<nowiki>*</nowiki> 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 and status of these rebuilds
+* creates/updates a module 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 and 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 the artifacts
+** "all green" meaning everything has been rebuilt = CVE fixed everywhere, so they can make a press release about it
+=== WHAT - the technical side ===
+There will be three entities:
+# '''components''' (RPM package)
+# '''modules'''
+# '''artifacts''' (modular repo, iso, docker image)
+And there would be three basic functions:
+# '''Search''' components, modules, and artifacts.
+# Browse ''''relations'''' between components, modules, and artifacts.
+# See '''details''' of components, modules, and artifacts.
+Details would as follows:
+# 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
+# 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
+# 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.
+[[File:BPO-relationships.png|600px]]
+==== 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.
@@ Line 16: / Line 77: @@
-== Relationships ==
+== HOW ==
-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.
+This is a question for the next sprint #10.
+The BPO would be probably:
+Read only. Web UI + API.
-[[File:BPO-relationships.png|600px]]
+Database that would remember everything and will be updated by:
+- querying other components
+- listenning to fedmsg