72 lines
3 KiB
ReStructuredText
72 lines
3 KiB
ReStructuredText
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.
|