Hi ,

How about an option for throttling number of max puppet clients being active - then puppet client time to run has come it registers at the puppetmaster - and once there is below max allowed active puppet clients running - puppetmaster initiates the client run (puppet client needs to have "listen=true" for that to work). Priorities can also be added easily. This also gives you easy visibility on then running puppet every X minutes becomes a bottleneck. This ca be probably done with mcollective - but requires a separate daemon process to manage the queue waiting puppet clients. The advanate of separate daemon is that it can have a view of more than one puppetmaster. The disadvantage is that puppet clients can still connect directly puppetmaster avoiding the queue altogether.
So it looks like a builtin puppet queue functionality is a better choice.

wdyt?

Alex

On 11/05/2011 06:42 PM, Nigel Kersten wrote:
On Thu, Nov 3, 2011 at 12:41 PM, Jo Rhett <jrh...@netconsonance.com <mailto:jrh...@netconsonance.com>> wrote:

    Nigel, As you've said, the time chosen for the run cycle will be
    consistent.  All of these settings are already set -- this isn't a
    question of how to change how often to run, it's how to affect the
    chosen runtime?

    I've got an awful lot of systems (> 100) which have decided to all
    roll at 28 and 58 minutes after the hour.  How can I rebalance them?


This should be what the splay settings do for you Jo.

Even though those agents all roll at 28/58 minutes past the hour, if you set splay to true, they'll then wait a random amount of time up to "splaylimit" before they *actually* perform the run.

The default setting for "splay" is off, so you won't see this behavior unless you explicitly turn it on.

Does that make more sense?



    On Nov 3, 2011, at 8:38 AM, Nigel Kersten wrote:
    On Thu, Nov 3, 2011 at 8:36 AM, Jo Rhett
    <jrh...@netconsonance.com <mailto:jrh...@netconsonance.com>> wrote:

        For a long time it appeared that run cycles were fairly
        balanced -- a few every 30 seconds over the 30 minute period.
         Right now I'm seeing more than 100 systems hit in the same
        minute: 28 and 58 minutes after the hour.  Is there some way
        to alter the spread of these systems back to even out the load?

        Or passenger options which could limit the effects of this?


    In your puppet.conf agent block:

        # How often puppet agent applies the client configuration; in
    seconds.
        # Note that a runinterval of 0 means "run continuously"
    rather than
        # "never run." If you want puppet agent to never run, you
    should start
        # it with the `--no-client` option.
        # The default value is '1800'.
        runinterval = 1800

    ...

        # The maximum time to delay before runs.  Defaults to being
    the same as the
        # run interval.
        # The default value is '$runinterval'.
        splaylimit = 1800

    ...

        # Whether to sleep for a pseudo-random (but consistent)
    amount of time before
        # a run.
        splay = false





        --
        Jo Rhett
        Net Consonance : consonant endings by net philanthropy, open
        source and other randomness

        --
        You received this message because you are subscribed to the
        Google Groups "Puppet Users" group.
        To post to this group, send email to
        puppet-users@googlegroups.com
        <mailto:puppet-users@googlegroups.com>.
        To unsubscribe from this group, send email to
        puppet-users+unsubscr...@googlegroups.com
        <mailto:puppet-users%2bunsubscr...@googlegroups.com>.
        For more options, visit this group at
        http://groups.google.com/group/puppet-users?hl=en.




-- Nigel Kersten
    Product Manager, Puppet Labs



-- You received this message because you are subscribed to the
    Google Groups "Puppet Users" group.
    To post to this group, send email to
    puppet-users@googlegroups.com <mailto:puppet-users@googlegroups.com>.
    To unsubscribe from this group, send email to
    puppet-users+unsubscr...@googlegroups.com
    <mailto:puppet-users+unsubscr...@googlegroups.com>.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.

-- Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open
    source and other randomness

-- You received this message because you are subscribed to the Google
    Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com
    <mailto:puppet-users@googlegroups.com>.
    To unsubscribe from this group, send email to
    puppet-users+unsubscr...@googlegroups.com
    <mailto:puppet-users%2bunsubscr...@googlegroups.com>.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.




--
Nigel Kersten
Product Manager, Puppet Labs


--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to