bodhi/updates system status

[Michael Schwendt]

On Tue, 13 Feb 2007 17:54:46 -0500, Luke Macken wrote:

> the system is going to need to access the build
> results of plague anyway, so I'm wondering if it would be best to
> implement some sort of xmlrpc call to have plague stage the packages for
> us?  Since plague and bodhi (among other new pieces of infrastructure)
> are in different co-locations, we definitely need some sort of way to
> communicate.  SSHFs was mentioned as a potentially viable solution, along
> with rsync hackery; any suggestions?

Access to the build results so far has been on the local fs. An exclusive
lock file is shared between plague and the pushscript to handle access to
the needsign repositories.

As soon as build results are to be mirrored from another location, it
would need something different in order to work only on complete build
results.

Querying plague would be beneficial anyway, since else you cannot map
build job numbers to packages and vice versa. And, of course, what is
currently implemented in a brute-force way is the removal of old and
pushed build results from the needsign repo after two days. With a change
in infrastructure, plague could do that itself. But before it could, it
needs input from the push front-end (like appropriate status feedback
similar to "plague-client finish <jobid>", which needs admin privileges so
far, however).

> > * "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.
> 
> How do you suggest we make better use of them?  I'm fairly ignorant in
> the ways of plague, so I don't know how the current staging of a
> build-job results really works.  At the moment there is only a single physical
> updates-stage on disc. When a package is "pushed", it is copied from the build
> result over to this updates-stage.  Before the push an update is either
> in 'testing', or is waiting to be signed/pushed/moved.
> 
> It seems like having some of these staging hooks in plague itself might be a
> good idea, instead of pulling and moving packages out from under it.

Package status so far:

 1 - needsign
 1.2 - needsign/EXCLUDED
 2 - needsign/PUSHED

In the future, it needs more stages, doesn't it? (and the concept
of collections adds on top of that)

 1 - needsign
 1.3 - signed
 2 - target updates testing (signed or unsigned)
 3 - target updates released (signed or unsigned)
 4 - unpush (signed or unsigned)
 5 - finished

1 is the multi-arch repository which is available to all build servers.

5 is not used yet, since telling plague about it needs admin privileges,
and at the level of the pushscript we don't know about job numbers.

For 2-4, it needs a database to keep track of the current package status
and location, and it also needs the places where to store the packages
temporarily. Where is that? Automatic or manual signing aside, packages
need to be available to the buildsys all of the time, regardless of
whether they are signed or unsigned or pushed to a public repository or
moved from "testing" to "released" (so it is possible to build test
updates against eachother, but also to avoid building final updates
against test updates - or this a grey area?).