Hello, after successfully using koji on a single machine we've hit a performance bottleneck, hence we're extending our build infrastracture by adding new builders.
There's a step which is not clear to me: /mnt/koji on the main machine should be remotely mounted read-only to the builders, right? is there any preferred mount method (nfs/sshfs/...) which is known not to be a source of issues?
On 11/23/2010 11:17 AM, Alan Franzoni wrote:
Hello, after successfully using koji on a single machine we've hit a performance bottleneck, hence we're extending our build infrastracture by adding new builders.
There's a step which is not clear to me: /mnt/koji on the main machine should be remotely mounted read-only to the builders, right? is there any preferred mount method (nfs/sshfs/...) which is known not to be a source of issues?
We usually use nfs for this.
Mike Bonnet píše v Út 23. 11. 2010 v 11:24 -0500:
On 11/23/2010 11:17 AM, Alan Franzoni wrote:
Hello, after successfully using koji on a single machine we've hit a performance bottleneck, hence we're extending our build infrastracture by adding new builders.
There's a step which is not clear to me: /mnt/koji on the main machine should be remotely mounted read-only to the builders, right? is there any preferred mount method (nfs/sshfs/...) which is known not to be a source of issues?
We usually use nfs for this.
a builder that's not in the createrepo channel can access the required content from /mnt/koji also via http, mounted /mnt/koji on builder is not a strict requirement
Dan
Not sure if this is related or not, but I'm curious about pruning old jobs/builds too. How is this done?
- Steve
On Tue, 23 Nov 2010, Dan Horák wrote:
Mike Bonnet píše v Út 23. 11. 2010 v 11:24 -0500:
On 11/23/2010 11:17 AM, Alan Franzoni wrote:
Hello, after successfully using koji on a single machine we've hit a performance bottleneck, hence we're extending our build infrastracture by adding new builders.
There's a step which is not clear to me: /mnt/koji on the main machine should be remotely mounted read-only to the builders, right? is there any preferred mount method (nfs/sshfs/...) which is known not to be a source of issues?
We usually use nfs for this.
a builder that's not in the createrepo channel can access the required content from /mnt/koji also via http, mounted /mnt/koji on builder is not a strict requirement
Dan-- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
On 11/23/2010 11:46 AM, steve.webb@beatport.com wrote:
Not sure if this is related or not, but I'm curious about pruning old jobs/builds too. How is this done?
koji-gc (in the koji-utils subpackage) will delete old unreferenced builds. I recommend running it nightly via cron (or perhaps weekly if your system doesn't see a lot of use). However, even deleted builds have a token presence in the database.
On Tue, Nov 23, 2010 at 12:24:05PM -0500, Mike McLean wrote:
On 11/23/2010 11:46 AM, steve.webb@beatport.com wrote:
Not sure if this is related or not, but I'm curious about pruning old jobs/builds too. How is this done?
koji-gc (in the koji-utils subpackage) will delete old unreferenced builds. I recommend running it nightly via cron (or perhaps weekly if your system doesn't see a lot of use). However, even deleted builds have a token presence in the database.
Could the Fedora rpm be extended to already have this included in the default configuration? Together with the script to clean up /mnt/koji/work?
regards,
Florian La Roche
On 11/23/2010 11:45 AM, Dan Horák wrote:
a builder that's not in the createrepo channel can access the required content from /mnt/koji also via http, mounted /mnt/koji on builder is not a strict requirement
Such a builder will need topurl (instead of topdir) specified in kojid.conf.
buildsys@lists.fedoraproject.org
-
Alan Franzoni -
Dan Horák -
Florian La Roche -
Mike Bonnet -
Mike McLean -
steve.webb＠beatport.com