On Wed, Sep 26, 2012 at 7:58 AM, mpapo - Michaël Pailloncy
<mpapo....@gmail.com> wrote:
>
> - Do you think it would be interesting to have a master only used to monitor
> the jobs (0 executor, all builds are delegate to slaves) ?
>
> This could be interesting to have a more stable and more reliable master.
I don't think it really matters as long as you have the resources in
the right places for the jobs you are running. However, that is
somewhat easier to manage when all jobs go to a pool of slaves. You
at least would not want the builds to be happening on the same
physical disk where the jenkins master job directory resides.
> - On the other hand, do you think it could be interesting to use multiple
> masters ? One for each team for example ?
I would only do that if you need to closely control access permissions
or have problems with sharing resources.
> This could be nice to have a more specialized master per team but I guess it
> must increase the maintenance time.
There is hardly any maintenance time for a yum-installed jenkins
instance, but it might be harder to keep the pools of slaves matched
to the jobs with several masters. I'd make this decision more on
management/budget concerns than anything technical.
> I need feedbacks from the community to choose the best architecture :
> How many jobs do you manage ?
200+ currently, and don't expect problems with more. Frequency of
builds might be a better metric and I don't know where to find a
meaningful metric for that (like average queue wait).
> What are the characteristics of your architecture ? (number of slaves, of
> master ??)
1 master, 17 slaves, some are seldom-used architectures.
> Would you prefer to use a slave with large capacity, or more with capacities
> smaller?
More, but capacity needs to be 'large enough'. Most of our slaves are
VMs running about 4 to a physical host (a mix of frequently/seldom
used instances...). I like to have jobs tied to labels, enough
slaves in a labeled group that having one or two down for maintenance
won't be noticed, and nothing of importance ever stored on a slave so
you can just spin up a new VM image as a replacement if you have any
problems.
--
Les Mikesell
lesmikes...@gmail.com
