arc/docs/pdc/split.rst

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.