I think this subject has come up several times. I know I have suffered with it for a long time myself. I can see situations where each method would be suitable so we should be able to configure it both globally at the label-level. So for example nodes with the label "labelA" have roaming mode set to "build on last node" and nodes with label "labelB" have roaming mode set to "build on any available". I would suggest this for a plugin but it is likely to also require core changes.
On Monday, January 21, 2013 8:01:01 PM UTC, Jan Seidel wrote: > > Sorry for the late reply. > I did lose this thread out of sight due to serious workload going on > here... > Mike got it right. The jobs will stay in the build queue and wait for a > machine even if 15 executors on other machines are ready to go. > The approach Mike suggests is not really feasible. There are 200 jobs > running on the cluster. It would be insane to set up slaves with 1 or a few > executors and restrict the jobs. I would never stop to reconfigure as the > setup changes in a very agile manner. > And Jenkins is overstressed with too many slaves on one machine. I am > facing troubles with offline slaves if a machine has 8-10 slaves running. > The result is that I have to start them manually -.- So more slaves on one > machine is not the solution. Rather fewer with more executors to make sure > an executor is available at all times. > But that is IMHO a bit insane and pretty upsetting to see one or two > machines drowning in build jobs while the other also could compute for SETI > as they ain't utilized. > > I am now trying to reconfigure the entire job topology to get as many jobs > of a specific type running on one machine with also comes along with > restrictions. Still no joy but I may be able to make it a bit more comfy. > > Any ideas would still be appreciate though. > > Cheers > Jan > > Am Donnerstag, 5. April 2012 11:59:07 UTC+2 schrieb Jan Seidel: >> >> Hi there, >> >> my question is already stated in the title as you can see :) >> >> I know that you can let jobs "roam" in a node cluster but can you let >> it REALLY ROAM? >> Jenkins tries to let jobs build on nodes which already have been used >> for building that particular job. >> That clutters some build queues while other nodes are picking nose. >> >> The idea was probably to preserve disk space. But I don't need that >> intention. "Unimportant jobs" delete their entire workspace upon >> finish while the important ones store everything until next run. These >> important jobs have a separate harddisk with loads of space. >> >> I have not only several executors running on each sever but also up to >> 3 instances of jenkins slaves for better usage of system ressources >> and to box very special jobs. Each slave instance is located on its >> own harddisk. >> That way do the special jobs and the slaves have exclusive access to >> ressources and the jobs may roam in their very own realm. >> Sounds a bit weird but works perfect except for this '*%&"%ยง# >> preferences to build on the same node that has build the job before. >> >> The excessive use of the harddisk slows all the builds in a senseless >> way as the bus reaches the capacity limit on spikes which happen if >> several jobs spawn at the same time and updates their workspace while >> there still are loads of unused ressources available on other machines >> -.- >> >> I see at the moment just one solution: split the cluster into more >> slaves with less executors and reassign the jobs. >> But that is counteracting my idea a bit as this turns from performance >> improvement, scalability and convenient usability to further >> performance improvement and alleviated administration. >> >> Has someone an idea how to remove this preference of Jenkins and >> simply let the jobs build where most executors are available? >> >> Cheers >> Jan > >
