Re: PDC replacement proposal

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

 



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

_______________________________________________
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

[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