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@xxxxxxxxxxxx> > 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: > > > > > > > > > > > > 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: > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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
