Roles of PDC and BPO in Modularity – please give me feedback

1 minute read

There has been some confusion about the roles of PDC and BPO in Modularity as the roles might seem overlapping. This document will briefly explain the roles of both services and highlight the main differences.

Long story short:

  • PDC is a database that stores module metadata and dependency graphs
  • BPO is a web UI to display module build state and probably to browse some metadata

    • Main overlaps:

  • BPO has its own database. However, the database acts as a cache only to make the UI fast. All the data can be lost and recovered from other services such as Orchestrator and PDC.
  • PDC has its own web UI. However, browsing and displaying modules has not been implemented. And even if it was, PDC does not/should not store data such as build state.

    • From my understanding, this design has been already valid on the Modularity Infra wiki page: https://fedoraproject.org/wiki/Modularity/Architecture/Infra?rd=Modularity/Infra

    PDC – Product Definition Centre

    PDC is the primary database for module metadata such as:

  • Name, stream, release – or however are these going to be called
  • Dependencies and components
  • Koji tags
  • Maybe information such as SLA?

    • It provides a REST API to access and manipulate this data.

    A part of PDC is also a web UI that will not be used in Modularity.

    BPO – Build Pipeline Overview

    BPO is a single web UI that will watch over the whole pipeline. Its primary function is to show the build state of each module.

    Users will be also able to browse module metadata such as:

  • Dependencies
  • Components
  • Install profiles

    • BPO uses its own database as a cache only to make the UI faster. The database:

  • Will be updated by fedmsg and also queries of other services as reactions to some messages.
  • Can be deleted and recovered from other services.

    • Updated: