How to find the time when a Puppet manifest is executed

[elliott]

I'm wondering if anyone knows a good way to get the date and time when a portion of code in a Puppet manifest is actually executed. Sometimes my manifests take a long time to run, and I need to schedule a task to occur soon after the end of the run, no matter when that occurs.

I have tried the time() function, setting a variable using generate() (using the date function on the Puppet master), and even creating a custom fact, but everything I've tried gets evaluated when the manifests are parsed on the server, rather than when they actually execute on the client.

Any ideas? The clients are all Windows, FWIW.

Thanks in advance!

[Felix Frank]

Ugh, that's too bad.

Also FWIW, I did this on linux using "echo <task> | at now+3min", which
works out of the box as long as "atd" is running.
Perhaps a similar crutch can be created using the Windows Task Scheduler.

Regards,
Felix

[elliott]

On Monday, January 27, 2014 9:17:18 AM UTC-8, Felix.Frank wrote:

Ugh, that's too bad.

Haha, indeed.

 

Also FWIW, I did this on linux using "echo <task> | at now+3min", which
works out of the box as long as "atd" is running.
Perhaps a similar crutch can be created using the Windows Task Scheduler.

Thanks for the idea, however I couldn't find an easy way to get the time 3 minutes from now in the Windows CLI (note: I am NOT a Windows script expert, there may be a way).

I did end up finding a way that will work for me.  It's ugly, but I'll document it for reference.

[elliott]

The fix I found for this is to schedule the task using an XML template with the <Repetition> parameter specified (you can edit these settings under Task Properties > Triggers > Edit > Advanced).  The task repeats every minute for 15 minutes after the start time.

The StartBoundary parameter is set to the time on the Puppet server (this is the compile time for the manifest, so anywhere from 1 to 10 minutes before the run completes).  In reality the task will start the next minute after the run finishes, which is fine for my purposes.

It's UGLY, but it works :)

[jcbollinger]

You could try wrapping your task in a script that defers running it until the agent's lock file disappears.  That would be cleaner and at least slightly more elegant.


John

[elliott]

On Tuesday, January 28, 2014 6:02:09 AM UTC-8, jcbollinger wrote:

You could try wrapping your task in a script that defers running it until the agent's lock file disappears.  That would be cleaner and at least slightly more elegant.

Oh good point.  That would be beyond my limited Windows-scripting abilities, but it would certainly be possible I think.

John