Infrastructure/arc
3
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

fix parsing errors and sphinx warnings

Browse source 
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
This commit is contained in:
Ryan Lercho 2023-11-16 08:02:56 +10:00 • committed by zlopez
parent 8fb9b2fdf0
commit ba720c3d77
98 changed files with 4799 additions and 4788 deletions
Download patch file Download diff file Expand all files Collapse all files

57
docs/pdc/split.rst
View file

@ -1,5 +1,5 @@
Proposal to retire PDC by splitting it among existing services
====================
==============================================================
Based on our research, currently we are using PDC for:
@ -10,10 +10,12 @@ Based on our research, currently we are using PDC for:
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-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/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
@ -21,47 +23,50 @@ Bodhi
-----
Bodhi would take over responsibilities of
- /rest_api/v1/releases/
- /rest_api/v1/component-branches/ - partially, just the critical-path flag
- /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.
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-*
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.
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
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:
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
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.
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/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.
/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.