bodhi/updates system status

[Bill Nottingham]

Luke Macken (lmacken at redhat.com) said: 
> > * 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?
> 
> That shouldn't change; 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?

Well, *assuming* we're going to tie bodhi to koji (as opposed to
having it target both), it depends on how we set koji up. 

> > * "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.

So, I think we're going to need a middle-stage tool between koji and
bodhi/pungi; there's logic like multilib selection, package selection,
interaction with signing, etc. that should all be in one place.

Bill