Mikesell, Sorry for responding a bit late, but it is better than not at all!
We have a setup where: 1. The Nodes/Slaves are chosen from the master by Node-Label. 2. We use the MultiJob plugin to start all jobs from the master. 3. The WORKSPACE is determined by the parent JOB/BUILD on the master, and passed down to each child job/build. We had to slightly modify AbstractProject.java, AbstractBuild.java and resources/lib/hudson/project/config-customWorkspace.jelly such that the parent JOB/BUILD could allocate the WORKSPACE using the parent Job's CustomWorkspace and not the Node's "Remote FS Root" path. This setup allows all of the builds to share the machines without any conflict for the build's WORKSPACE. I hope that this helps. Let me know if you would like to know about the code changes we made to support this setup. ... Mgimza On Tue, Oct 16, 2012 at 11:57 AM, Les Mikesell <lesmikes...@gmail.com>wrote: > On Tue, Oct 16, 2012 at 2:29 AM, Shen Hui <shenhu...@baidu.com> wrote: > > Because we have too many jobs (more than 1 thousand) coming from > different > > divisions; we wish each division use a separated master, and all masters > can > > share a slave pool. > > > > One master with 1000+ jobs and 20 slaves doesn't sound like a big > problem, other than the one mentioned here recently about keeping a > lot of archived builds which jenkins currently keeps in memory. > > If you really need separation, maybe you can set up some sort of cloud > of VMs for slaves and let each master spin up a certain number on > demand. I can see where a concept of shared slaves - or perhaps more > generally, scheduling jobs based on slave load (prefer least loaded, > defer at some threshold) would be very useful, but I don't think there > is anything that currently works that way. > > -- > Les Mikesell > lesmikes...@gmail.com >
