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

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 https://fedoraproject.org/wiki/Critical_path_package is in https://pagure.io/fedora-comps/tree/main when you search for groups with critical-path-* prefix. For example: https://pagure.io/fedora-comps/blob/main/f/comps-f35.xml.in#_622

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 https://docs.pagure.org/releng/sop_update_critpath.html but now we have https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/pdc_update_critpath.py

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

https://github.com/fedora-infra/bodhi/blob/master/bodhi/server/util.py#L192

Pagure-dist-git

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.