Added PDC

docs/initiatives.rst

@@ -6,3 +6,4 @@ Initiatives
 
     datanommer_datagrepper/index
     monitoring_metrics/index
+    pdc/index

docs/pdc/index.rst

@@ -0,0 +1,81 @@
+PDC
+========================
+
+PDC replacement research
+========================
+
+`PDC <https://pdc.fedoraproject.org/>`_ is repository and API for storing and querying metadata related to packages and product releases.
+We rely on information in it to produce Fedora releases, manage retirement of packages and more.
+
+Our current deployment running on https://pdc.fedoraproject.org/.
+
+It uses https://github.com/product-definition-center/product-definition-center/tree/python-pdc-1.9.0-2
+
+The software is orphaned by it's original maintainers with version requiring EOL version of python and EOL version of Django Framework,
+this means we need to upgrade it or replace it.
+
+Current users of PDC
+========================
+
+Based on conversations with coleagues from Releng and Fedora QA,
+and cursory investigation of our repositories we use pdc API or through CLI client in:
+
+- releng scripts
+- fedpkg
+- pungi
+- fedfind
+- bodhi
+- pagure
+- modulebuildservice 
+- mirrormanager scripts in ansible-repo
+- ODCS 
+- new hotness
+- fedora messaging 
+- osbs client
+
+As a part of this investigation we want to create exhaustive list, with analysis of the actual PDC use-case in each application.
+
+Solutions to be explored
+========================
+
+We have sevral options:
+
+- Upgrade PDC to supported version of Django and take over the maintenance
+- Use a database with a simple api gateway like Postgrest or Prest in front of it
+- Create a new bespoke application that better suits our needs
+- Incorporate the functionality we need to other applications we already have (Pagure/Bodhi/Datagrepper)
+
+Preliminary notes on maintianing current PDC
+--------------------------------
+
+This would require significant investment, as it would require several upgrades of underlying software
+and probably even a Python 2.x to 3.x migration as well.
+
+Moreover, based on the discussions within CPE:
+
+- current PDC is more complex than we need
+- we want to avoid maintaining another application
+
+Because of this, we won't focus on this avenue of exploration.
+
+Preliminary notes on database-derived api for PDC
+-------------------------------------
+
+Based on our discussions, we mostly use simple CRUD API,
+which means that a new database-model that would better suit our needs
+could be all we need to migrate.
+
+The biggest advantage of this approach is using off the shelf service,
+where only thing we need to maintain is the database-model, clients,
+and keeping the software up-to-date.
+
+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