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/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:
Pagure-dist-git would take over responsibilities for
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.
/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.