Puppet: System Administration Automated

Support

Ticket #1100 (new enhancement)

Opened 11 months ago

Last modified 9 months ago

client should not sleep for $splay_time when triggered by puppetrun

Reported by: alden Assigned to: community
Priority: normal Milestone:
Component: unknown Version: 0.24.1
Severity: normal Keywords: puppetrun splay
Cc: Triage Stage: Accepted
Attached Patches: Code Complexity: Easy

Description

When a client is triggered by puppetrun, it still sleeps for $splay_time before running. I've hacked together a (probably incorrect) patch that is working for me for now. :)

Attachments

patch (1.0 kB) - added by alden on 02/26/08 23:33:24.
updated-patch (4.8 kB) - added by alden on 02/28/08 22:17:10.
I've updated the patch against the latest git pull (which means I've removed my patches for #1101 and #1103).

Change History

02/26/08 23:33:24 changed by alden

  • attachment patch added.

02/27/08 01:26:31 changed by jamtur01

  • complexity changed from Unknown to Easy.
  • stage changed from Unreviewed to Needs more info.

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 ...

(follow-up: ↓ 4 ) 02/27/08 05:33:51 changed by luke

  • type changed from defect to enhancement.
  • summary changed from client sleeps for $splay_time when triggered by puppetrun to client should not sleep for $splay_time when triggered by puppetrun.

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.

02/28/08 03:13:31 changed by alden

  • patch changed from None to Code.

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()").

02/28/08 22:17:10 changed by alden

  • attachment updated-patch added.

I've updated the patch against the latest git pull (which means I've removed my patches for #1101 and #1103).

(in reply to: ↑ 2 ) 03/07/08 22:15:57 changed by RyanDooley

Replying to 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.

04/08/08 18:00:26 changed by luke

  • stage changed from Needs more info to Accepted.

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.

04/24/08 08:11:31 changed by luke

  • component changed from client to unknown.