diff --git a/docs/pdc/endpoints.rst b/docs/pdc/endpoints.rst index 1c9ece7..6fdbd48 100644 --- a/docs/pdc/endpoints.rst +++ b/docs/pdc/endpoints.rst @@ -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 ---------------- :: diff --git a/docs/pdc/index.rst b/docs/pdc/index.rst index 3c584dd..a3a5ae6 100644 --- a/docs/pdc/index.rst +++ b/docs/pdc/index.rst @@ -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. \ No newline at end of file diff --git a/docs/pdc/split.rst b/docs/pdc/split.rst new file mode 100644 index 0000000..e6dc4b6 --- /dev/null +++ b/docs/pdc/split.rst @@ -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. \ No newline at end of file