Luke Macken (lmacken(a)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