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