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?
In the pkgdb time, the EOL status was basically simply computed from the release
status, ie: what we still have at:
(looks like we should fix the branchname in that json)
but we could just go back to this :)
Pierre