Re: PDC replacement proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 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:

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:


> 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. 

> 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

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:
> 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.

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).


Attachment: signature.asc
Description: PGP signature

devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux