Hello all, it took us a few years but we are finally getting rid of the PDC project. Thanks to the ARC research we identified use cases in our tooling and proposed solution.
The essential functionalities currently provided by PDC will be re-implemented in other applications within our release infrastructure, as there are no immediate plans for their replacement and are currently maintained
This work is anticipated to span several months for completion. However, before we embark on this endeavor,
we would like to proactively share our proposed solution with all of you and gather your valuable feedback.
Below, we outline our strategy to preserve the core functionality of PDC by leveraging existing applications within our ecosystem.
Current uses of PDC:
Currently, we rely on the Package Database (PDC) for various data management tasks, including:
Critical Path Package Tracking: Bodhi leverages PDC to track packages on the critical path.
Retirement of Packages and Service Level Agreements (SLAs): PDC assists in managing the retirement of packages and their associated SLAs.
Metadata for Nightly Composes: Our Release Engineering and Fedora Quality Assurance teams rely on PDC for metadata related to nightly composes.
More info on the usage can be found here: https://fedora-arc.readthedocs.io/en/latest/pdc/users.html
Specific Endpoints in Use:
We interact with the following endpoints in PDC to access and manage our data:
/rest_api/v1/global-components: This endpoint stores package names.
/rest_api/v1/component-branches: Here, we store SLAs, track active/retired status, and manage the critical-path flag.
/rest_api/v1/component-branch-slas: An auxiliary endpoint dedicated to SLAs.
/rest_api/v1/compose-images: This endpoint stores essential files, such as composeinfo.json and image-manifest.json.
/rest_api/v1/releases: It houses metadata on various release types (e.g., GA, updates, EUS, AUS, ELS, fast, updates-testing) for product versions, indicating their active status.
/rest_api/v1/rpms: This endpoint establishes links between RPM packages and composes.
/rest_api/v1/product-versions: Here, we store major versions of Fedora.
More info on the endpoints: https://fedora-arc.readthedocs.io/en/latest/pdc/endpoints.html
Upcoming Changes
Bodhi:
Bodhi will assume responsibility for the following tasks, reducing our reliance on PDC:
/rest_api/v1/releases/: Bodhi will now manage release-related data.
/rest_api/v1/component-branches/: Specifically, Bodhi will handle the critical-path flag.
Bodhi's existing framework aligns well with releases and components. To enhance this, we will create an auxiliary table that pairs this data with additional metadata,
predominantly focusing on the critical-path flag. Previously, we had to query this information from PDC.
It's essential to note that PDC is not the definitive source of truth for critical-path packages. The Fedora Project Critical Path Package Wiki indicates that the source of truth lies within the Fedora Comps repository.
You can find specific information by searching for groups with the "critical-path-*" prefix, as demonstrated here.
While the data is accessible through DNF, generating it can be time-consuming. PDC serves as a pre-computed cache.
Previously, we followed this process to update it, but now we have transitioned to using this method.
The primary application of this information during the Fedora release cycle is in Bodhi, where it is used to enforce stricter requirements on critical-path package updates. For further details, please refer to this link.
Pagure-dist-git:
Pagure-dist-git will take over several responsibilities from PDC, including:
/rest_api/v1/product-versions
/rest_api/v1/global-components
/rest_api/v1/component-branches/
/rest_api/v1/component-branch-slas/
Pagure already has a robust database of global components (repositories) and product versions (repository branches).
It utilizes the PDC API to query component branches when a package is retired, and an auxiliary table in Pagure-dist-git will store the reasons for orphaning these components.
A list of all identified uses of PDC API can be found in the original ARC investigation: https://fedora-arc.readthedocs.io/en/latest/pdc/users.html
Projects not considered in the original arc investigation:
MDapi
Toddlers
Toddlers took over the functionality of the fedscm-admin tool and it's more or less a 1:1 rewrite of the tool, use cases should be the same as fedscm-admin.
Remaining Endpoints:
A few endpoints will remain unchanged:
/rest_api/v1/compose-images/: Given that we primarily store JSON blobs here, we have decided, based on discussions, to store the JSON data on a network-accessible file server.
/rest_api/v1/rpms/: This endpoint does not currently have a dedicated application, but our Quality Assurance team uses it to query packages in specific composes.
CPE is scheduled to commence work on this project in approximately two weeks. If you have any feedback regarding the proposed solution to facilitate the decommissioning of PDC
or if you have any questions or require additional information, please don't hesitate to get in touch with us.
Your input and inquiries are greatly appreciated.
--
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
