On Mon, Sep 04, 2023 at 04:51:22PM +0200, Tomas Hrcka wrote: > 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: > > > 1. > > Critical Path Package Tracking: Bodhi leverages PDC to track packages on > the critical path. As Adam mentioned this is already not in pdc. ;) > 2. > > Retirement of Packages and Service Level Agreements (SLAs): PDC assists > in managing the retirement of packages and their associated SLAs. Yeah. The super big one is that its queried from a git commit hook for all src.fedoraproject.org git commits. Right now if pdc is down, no one could commit anything. > 3. > > 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 mass rebuild of modules can be dropped. ;) fedscm-admin is now the scm requests toddler. It still uses pdc tho of course. > Specific Endpoints in Use: ...snip... > 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. Do note that bodhi still has a window after we are 'go' for a relase where it thinks it's released, but it's not yet. We probibly need to address this if we are moving this to bodhi. > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the > critical-path flag. Already done. ...snip... > > 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. So, I know this will work... but it means more closely tying ourselves to pagure-dist-git. ;( With modules going out of the picture, most branches just have the release cycle of the fedora or rhel release they are based on, so couldn't we just default that somewhere? There's also flatpaks, but I think we could also tie them to release eol's. So, is it possible to just not keep these things? > > 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. yeah. > 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. What server? Where? I think the only thing that uses this is fedfind? I really suggest at the start of this work, we just plan out exactly what changes before doing anything. (ie, merge this exact PR that changes this). kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
