One of my former co-workers did a talk about Mcollective at PuppetConf.
People involved in this thread might find it useful :) He gives some
examples about doing rolling restarts, you could do something very similar
with orchestrating agent runs.
http://puppetlabs.com/presentations/intro-systems-o
On Monday, September 2, 2013 12:01:46 PM UTC-4, Stuart Cracraft wrote:
>
> How can this be randomized within a range?
>
> I believe someone mentioned "splay" ?
>
> My fear is that all the boxes will request at a similar some day, by chance
> and send a tidal wave over to the master.
>
> On Sep 1, 2
Stuart,
If I'm understanding your needs correctly, this may be what you're looking
for:
http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php
On Monday, September 2, 2013 11:01:46 AM UTC-5, Stuart Cracraft wrote:
>
> How can this be randomized within a range?
>
> I bel
On 2 September 2013 17:01, Stuart Cracraft wrote:
> How can this be randomized within a range?
>
>
I don't think it can; it suffers from the same issue as splay does, which
I explained in some detail last week.
>
> My fear is that all the boxes will request at a similar some day, by chance
>
How can this be randomized within a range?
I believe someone mentioned "splay" ?
My fear is that all the boxes will request at a similar some day, by chance
and send a tidal wave over to the master.
On Sep 1, 2013, at 10:27 PM, Rahul Khengare wrote:
> You can use different runinterval for each
On 30 August 2013 10:42, Matthew Burgess wrote:
>
> So, instead of running puppet in daemon mode, I'd look to use something
> like mcollective to control when the agents check in with the master.
>
You could of course just set up a cron job on each host, ensuring they
check in at different times.
In your situation, I'd be tempted to not run the puppet agent in daemon
mode at all so that you can retain full control of when the agents will
check in. I can't see how the splay option will help avoid concurrent
checkins:
Imagine HA node 1 is rebooted for whatever reason and comes back up at
12
There *is* a (semi-)randomizer. Look at the splay option in the puppet.conf
http://docs.puppetlabs.com/references/latest/configuration.html#splay
-- Peter (from phone)
On Aug 29, 2013, at 10:21 PM, Stuart Cracraft wrote:
> I think there should be a randomizer built-in to prevent this without t
I think there should be a randomizer built-in to prevent this without these
kinds of manual requirements.
On Aug 29, 2013, at 5:16 PM, Matt Shields wrote:
> How about turning off the puppet agent on all the machines, make the change,
> then turning them back on a few at a time.
>
> Matt
>
>
How about turning off the puppet agent on all the machines, make the
change, then turning them back on a few at a time.
Matt
On Thu, Aug 29, 2013 at 4:50 PM, wrote:
> How do I avoid a situation where all of my Linux servers execute a service
> restart at the same time upon receiving a new conf
How do I avoid a situation where all of my Linux servers execute a service
restart at the same time upon receiving a new configuration change via
Puppet? I am trying to avoid any possibility that the service would be
unavailable for any length of time. The servers are behind a load
balancer
11 matches
Mail list logo
