There are a number of ways one might use to set up a stage instance of
koji that is based on a production instance. This is one that I have
used on my koji systems.
The two major bits of data that koji contains are:
1) the koji db
With the db it is pretty easy to make a duplicate db based on a
snapshot. The filesystem can be trickier. If you're lucky, your
filesystem may support writable snapshots, in which case, awesome.
Otherwise, you might like this approach.
Koji has supported the notion of split storage since 1.7.0. There's a
brief summary of how that works here:
In this staging approach, we mount the production volume READ-ONLY on
the staging systems, and make /mnt/koji/vol/prod on the _stage_ fs point
to that RO mount.
When we restore the database from the production snapshot, we update the
builds to point to the prod volume (seen the attached example script).
The stage koji instance will then know where to find them.
Because the builds have changed locations, the old repodata becomes
invalid, so all the repos need to be regenerated. The attached script
just marks them expired (which should trigger the kojira running in
stage to regen them).
The attached example sql script is based on one that I have used before.
It will need to be adapted to your particular case.
I've begun to notice a surprising accumulation of failed build logs our
Is there a way to get koji gc to find all the failed builds for a given
package (by name, since it isn't successful) and clean up all but the
latest failed build?
I expect that will return an embarrassing amount of disk on my system.....
Scientific Linux developer
Fermi National Accelerator Laboratory
We now have a new mailing list specifically for Koji development. I see
a few of you joined after I mentioned it in the Koji 2.0 planning email.
This list (buildsys(a)lists.fedoraproject.org) is still a good place to
ask questions, talk about deployment issues, and discuss topics specific
to Fedora's Koji instance. Of course, this list also covers a number of
other build related tools besides Koji.
Development specific emails should go to the new list. In particular,
patches to Koji should now go to koji-devel list for review.
I have been doing some test for past two days and experimenting with
TmpFS plugin of Mock.
I summarized my findings here:
The performance increase is huge and I believe Koji can do the same.
I.e. enable tmpfs plugin, set the tmpfs size to some big number and
create create big swap - if there is not such big partition available,
it can be done as a file in some data partition.