Re: bodhi/updates system status

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

 



On Wed, 31 Jan 2007 22:55:31 -0500, Luke Macken wrote:

> Hey all,
> 
> I made a blog post[0] recently about bodhi[1], which is the name of the new
> updates system for Fedora.  I layed out a bunch of milestones[2] for the
> project, 1.0 being the minimal functionality needed for Fedora 7.
> 
> If anyone is interested in helping out, feel free to grab any ticket;
> and if you have questions or don't know where to begin, don't hesitate to ask.
> 
> I'm hoping to bring bodhi up to 1.0 (and hopefully beyond) during the hackfest
> this weekend.  We'll see what happens :)
> 
> luke
> 
> [0]: http://lewk.org/blog/2007/01/30/bodhi
> [1]: https://hosted.fedoraproject.org/projects/bodhi
> [2]: https://hosted.fedoraproject.org/projects/bodhi/roadmap

The status updates raise a few more questions without that I've tried to
install the project locally:

* One of the screenshots,

https://hosted.fedoraproject.org/projects/bodhi/attachment/wiki/Screenshots/bodhi-push.png

shows a "Push Console" where a single build job's packages are pushed and
createrepo is run afterwards. A huge difference to real-world pushing is
that this single operation does not take just 3 seconds, but several
minutes for each repository.

I fail to see how pushing packages like this can be a real-time operation
managed through a web interface. Unless a queueing server runs in the
background, which handles access to the repositories. Access for a variety
of operations, not limited to metadata creation. Add pruning, repoview,
multi-lib stuff. These operations are mutually exclusive.

* Currently, we push to a local master repository on the buildsys server
and sync that another machine at RDU. This requires SSH-based
authorization. What are the plans to change that within a web-based
updates system?

* "Staging area": I've browsed the bodhi wiki pages in search for
information on how to make better use of stages in the life-time of a
build-job's results.

Currently, we push from within a single staging area, plague's
"plague-results" tree. Earlier attempts, like moving packages from one
stage to another, have broken the buildsys (in particular the needsign
repo) too often, because it takes time for published packages to find
their way from fedoraproject.org to download.fedora.redhat.com, and
meanwhile, any pushed package we don't keep in the needsign repo breaks
the build servers' dep-chains. The work-around, that has worked flawlessly
since then, is to mark plague-results directories as "PUSHED" with an
empty file:

http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/seedit/2.1.0-3.fc6/

That way we don't need to mess with the needsign repo rpms and metadata
and can keep the access read-only. With operations like "push" and
"unpush" and a testing repo it likely needs more to keep track of the
package life-cycle. What are the plans here?


[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux