Puppet

Wouldn’t it be better to do something to this:

def splay
       return unless Puppet[:name] != "puppetrun"
       return unless Puppet[:splay] 

Or at line 242 something like:

splay unless Puppet[:name] == "puppetrun"

Then splay isn’t executed if its the puppetrun binary. Haven’t tested this …

The problem here is that he wants splat disabled on the client (the machine he’s connecting to), not the machine that’s running puppetrun.

He specifically wants some way for the client to know if it was triggered with puppetrun rather than normally.

The problem I have with this request is that sometimes people will desire the current behaviour (so they can trigger many hosts at once) and sometimes they will desire instant triggers.

Ok – let me start with this is my first attempt at coding in Ruby, so please go easy on me. :–) I’ve attached a patch that implements —ignoresplay in both puppetd (where it ignores splay whenever it’s triggered by puppetrun) and puppetrun (where it tells the client puppetd to ignore the splay on the current run). This allows you to always ignore splay on puppetrun (by starting puppetd with —ignoresplay) or only when you specify (by passing —ignoresplay on puppetrun). This patch also includes fixes for #1101 (by adding “require ‘puppet/network/handler’” to puppetrun) and for #1103 (by replacing all of the parse_config lines with just “Puppet.parse_config()”).

Replying to [comment:2 luke]:

The problem here is that he wants splat disabled on the client (the machine he’s connecting to), not the machine that’s running puppetrun.

He specifically wants some way for the client to know if it was triggered with puppetrun rather than normally.

The problem I have with this request is that sometimes people will desire the current behaviour (so they can trigger many hosts at once) and sometimes they will desire instant triggers.

Since I think I posted this a quick comment:

In our environment I have a tool that triggers behavior on many machines and I taught it about puppet. The same tool has a splay feature built in so I can control how quickly my clients check in.

Now, that’s not for everybody and probably not even for me in the future as the plant grows in size but it would still be nice to have this option.

I’m willing to accept this, but I need some kind of testing to ensure it doesn’t break people’s existing systems.

This will cause backward compatibility issues with older clients, for the record. I don’t know how big of an issue that is, since people can just use an older version of the puppetrun executable.

I’ll need some kind of tests, or at least, runs that prove this works, before I accept this, though.

James Turnbull wrote:

Then splay isn’t executed if its the puppetrun binary. Haven’t tested this …

I would prefer an similar solution. puppted should ignore splay time, if you start puppetrun with —ignore-splay-time or some other option. So the user can decide if you will use splay time on puppetrun or not.

I’d like to re-visit this … using splay in a regular environment is really useful — but completely breaks the behavior of puppet kick if you want puppet kick to be immediate. Can we just get an option with puppet kick like —immediate..?

After 3 years, puppetrun (now kick) is still basically completely broken by this bug.

We use splay to prevent thundering herds in day to day operation, and it works great. The rationale here seems to be “let the admin run millions of hosts at once and prevent the thundering herd by using splay”, except there is already an option to do that. It’s called parallel:

   parallel: How parallel to make the connections. Parallelization
                    is provided by forking for each client to which to
                    connect. The default is 1, meaning serial execution.

Parallel doesn’t work though, because puppetrun/kick fails completely in the presence of splay, returning timeouts. Maybe I’m missing something, but what does “obey splay” do that “parallel” doesn’t? (Even assuming it didn’t time out, etc etc.)

DisConnect – kick works fine for me. What you’re actually saying is that your use of it is impaired.

What version are you testing?

With splay on, it fails. With splay off, it works as expected. We’re using 2.6.4-2ubuntu1 but this has been broken since splay was introduced.

Splay off:

$ sudo puppet kick -p 10 --foreground --host build36.foo.com 
Triggering build36.foo.com
Getting status
status is success
build36.foo.com finished with exit code 0
Finished

(and on the server: build36 puppet-agent[25310]: Finished catalog run in 23.66 seconds)

Splay on:

$ sudo puppet kick -p 10 --foreground --host build36.foo.com 
Triggering build36.foo.com
/usr/lib/ruby/1.8/timeout.rb:60:in `rbuf_fill': execution expired (Timeout::Error)
from /usr/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill'
from /usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
from /usr/lib/ruby/1.8/net/protocol.rb:126:in `readline'
...
from /usr/lib/ruby/1.8/puppet/application.rb:287:in `run'
from /usr/lib/ruby/1.8/puppet/util/command_line.rb:55:in `execute'
from /usr/bin/puppet:4
build36.foo.com finished with exit code 
Failed: build36.foo.com

And the server shows:

Feb 22 08:21:42 build36 puppet-agent[25231]: triggered run
Feb 22 08:25:01 build36 CRON[25344]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
...
Feb 22 08:26:01 build36 puppet-agent[25231]: Finished catalog run in 23.04 seconds

Splay shouldn’t apply to puppetrun since the same effect (don’t destroy the puppetmaster) can be accomplished by tuning your local —parallel setting.

I agree with DisConnect. This is extremely frustrating, and doesn’t seem to be documented ( i reference http://docs.puppetlabs.com/man/kick.html). The docs say “Trigger a puppet run”. Especially with the name “kick”, I take this to mean “now, immediate, forceful”. IMHO this is completely useless for those of us who run with —splay, We really need a way to trigger runs immediately.

Case in point: I just rolled out a new module in my “test” environment. I ended up typo-ing a variable name. 6 hosts pulled the new code, and promptly spit out errors, before I could get the fix pushed out. So… I wait half an hour for them to pull again? Or I have to SSH into each one and manually trigger a run? Because, since I’m using puppetd with splay, kick does absolutely nothing.