On Mon, Sep 11, 2023 at 03:08:50PM +0200, Tomas Hrcka wrote:
Sorry for the confusion with work that is already done, We can drop the critpath thanks Adam!
As it goes for EoL and package retirement we for the past few releases we are saving EOL date in bodhi. So getting EOL for specific release is not a problem once the release is out.
yeah, the reason we needed it in pdc before was stream branches.
I think once flatpaks are moved to the new setup we won't have any _new_ stream branches. However, if we are going to support updating modules for f37/f38, we may need to figure out something there...
For storing the orphaning reason and other potential metadata. We can store some of it in git in form of notes on branches not necessarily in pagure-disgit specific code-base.
yeah, I think moving some of this that makes sense into git is reasonable.
With toddlers i think the path is clear we need to use bodhi as a source of truth about releases. Similar work as on toddlers will need to be done on mdapi
For the compose metadata we can store the the json blobs on fedorapeople for now and search for some stable place.
I don't think we should use fedorapeople for anything like this. If we need just a space we could use /pub/alt/something/ ?
These are the things that fedfind/qa users? Do we have examples of this data?
Thanks for working on this!
kevin --
On Wed, Sep 6, 2023 at 12:23 PM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Tue, Sep 05, 2023 at 11:35:19AM -0700, Kevin Fenzi wrote:
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:
Critical Path Package Tracking: Bodhi leverages PDC to track
packages on
the critical path.
As Adam mentioned this is already not in pdc. ;)
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.
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: https://admin.fedoraproject.org/pkgdb/api/collections (looks like we should fix the branchname in that json) but we could just go back to this :)
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Tomas Hrcka fas: humaton libera.CHAT: jednorozec
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue