On Thu, Apr 5, 2012 at 4:59 AM, Jan Seidel <[email protected]> wrote:
> 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.
Not so much that as to let SCM updates work so you don't need to wait
for a full checkout of large jobs for the next build which will
typically have a small change.
>"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?
Normally the initial distribution would be more random in the first
place - perhaps you started with one node and built all the jobs
before adding others. All of our jobs are tied to labels, so if we
remove the labels from a node, all of its jobs will do their next
build on one of the others. You could force jobs to move with a
'restrict to' a different node, or force some separation by using
several labels just to make them spread out, but I don''t know of a
more dynamic approach. I think what you need is a way to specify in
the job that jenkins should clean up and forget where it ran last for
the jobs where you want that behavior.
--
Les Mikesell
[email protected]
