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.