Proposal to retire PDC by splitting it among existing services

Based on our research, currently we are using PDC for:

  • Bodhi knowing about packages on critical path

  • Retirement of packages and their SLA’s

  • Metadata on nightly composes used by RelEng and Fedora QA

The endpoints we use are:

  • /rest_api/v1/global-components - for storing package names

  • /rest_api/v1/component-branches/ - stores SLA’s, active/retired and critical-path flag

  • /rest_api/v1/component-branch-slas/ - auxiliary endpoint for SLA’s

  • /rest_api/v1/compose-images//rest_api/v1/compose-images/ - stores composeinfo.json and image-manifest.json

  • /rest_api/v1/releases/ - metadata on type (ga, updates, eus, aus, els, fast, updates-testing) of a release of a product version and if it is active

  • /rest_api/v1/rpms/ - liks rpms to composes

  • /rest_api/v1/product-versions - stores major versions of fedora


Bodhi would take over responsibilities of
  • /rest_api/v1/releases/

  • /rest_api/v1/component-branches/ - partially, just the critical-path flag

Bodhi already has concept that maps to releases and components, we should be able to create auxiliary table that will pair these with additional metadata, mostyl the critical-path flag, that previously had to be queried from PDC.

PDC actually isn’t the source-of-truth for packages on critical path. The source of truth, according to is in when you search for groups with critical-path-* prefix. For example:

The data is available through dnf, but generating it can be really slow, PDC is then used as a sort of a pre-computed cache.

To update it, we used to use but now we have

Only place we actually use the information during the fedora release is in Bodhi, to have stricter requirements on critpath package updates in Bodhi:


Pagure-dist-git would take over responsibilities for

  • /rest_api/v1/product-versions

  • /rest_api/v1/global-components

  • /rest_api/v1/component-branches/

  • /rest_api/v1/component-branch-slas/

Pagure already de-facto has a database of global-components (the repositories), and product-versions (repository branches) and it uses PDC api to query component-branches if the package was retired, with auxiliary table in pagure-dist-git storing reason for orphanning.

Remaining endpoints

/rest_api/v1/compose-images/ - as we are mostly storing json blobs, based on discussions, we should just store the json in network-accessible file-server.

/rest_api/v1/rpms/ - this is only information that so far doesn’t fit into any existing application. QA is using it to query what packages are in particular composes.