The two major bits of data that koji contains are: 1) the koji db 2) /mnt/koji
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:
https://lists.fedoraproject.org/pipermail/buildsys/2012-May/003892.htmlIn 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.
koji-stage-reset-example.sql
Description: application/sql
-- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
