WIP

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 
+/rest_api/v1/product-versions
---------------------
-
-::
-
-        {
-            "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
 ----------------
 
 ::

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
-- 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 retirement and sla's of packages could be moved to pagure-dist_git
+Tesponsibility for critical-path and releases can be moved to Bodhi
-- 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
-- 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::
+Create a new bespoke application that better suits our needs
-    :maxdepth: 1
+----------------------------------------------------
-
-    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.

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.