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

WIP

Browse source
This commit is contained in:
Adam Saleh 2021-05-05 17:15:22 +02:00
parent 05a3f496af
commit 010fdb0050
3 changed files with 70 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/pdc/endpoints.rst
View file

@ -96,7 +96,7 @@ rest_api/v1/compose-images/
}
}
rest_api/v1/compose-images/
/rest_api/v1/releases
-----------------------
::
@ -164,31 +164,7 @@ rest_api/v1/rpms
rest_api/v1/releases
--------------------
::
{
"active": false,
"allow_buildroot_push": false,
"allowed_debuginfo_services": [],
"allowed_push_targets": [],
"base_product": null,
"bugzilla": null,
"compose_set": [],
"dist_git": null,
"integrated_with": null,
"name": "Fedora Updates",
"product_version": "fedora-26",
"release_id": "fedora-26-updates",
"release_type": "updates",
"short": "fedora",
"sigkey": null,
"version": "26"
}
product-versions
/rest_api/v1/product-versions
----------------
::

38
docs/pdc/index.rst
View file

@ -14,11 +14,17 @@ this means we need to upgrade it or replace it.
Abstract take-away
------------------
Current approach we agree on:
- there is no silver bullet, it will require development effort
- responsibility for retirement and sla's of packages could be moved to pagure-dist_git
- responsibility for critical-path and releases can be moved to Bodhi
- nightly compose metadata requires new application, that would be much simpler than current PDC
There is no silver bullet, it will require development effort
Responsibility for retirement and sla's of packages could be moved to pagure-dist_git
Tesponsibility for critical-path and releases can be moved to Bodhi
Nightly compose metadata requires new application, that would be much simpler than current PDC
.. toctree::
:maxdepth: 1
split
users
endpoints
Previous work
-------------
@ -56,6 +62,8 @@ We have sevral options:
- Create a new bespoke application that better suits our needs
- Incorporate the functionality we need to other applications we already have (Pagure/Bodhi/Datagrepper)
Currently we are proposing primarily the last option.
Preliminary notes on maintianing current PDC
--------------------------------
@ -69,7 +77,7 @@ Moreover, based on the discussions within CPE:
Because of this, we won't focus on this avenue of exploration.
Preliminary notes on database-derived api for PDC
Preliminary notes on using Postgrest
-------------------------------------
Based on our discussions, we mostly use simple CRUD API,
@ -84,16 +92,7 @@ We have chosen two candidates to investigate based on the fact,
we probably want to utilize Postgresql on the backend:
- https://postgrest.org/en/stable/
- https://docs.prestd.com/
Things to investigate:
- database model that would suit the needs of our current users
- migration path (data import?)
- roles and integration with our account system
Preliminary notes on using Postgrest
--------------------------------
Postgrest as a simple api on top of a database model sounded promissing,
but after investigating how to integrate it with ou currentaccount system,
@ -103,9 +102,8 @@ it turned out we would need to maintain a separate service that would serve as a
This speaks against using Postgrest.
.. toctree::
:maxdepth: 1
Create a new bespoke application that better suits our needs
----------------------------------------------------
users
endpoints
We investigated using fastapi and fas, and the previously started fpdc proof of concept by Clement.
Based on discussions with others, we decided to investigate way to merge the existing functionality to the services we already maintain.

50
docs/pdc/split.rst Normal file
View file

@ -0,0 +1,50 @@
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.
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.