delayed effect of "puppet apply mumble.pp"

[Stuart Cracraft]

When I apply my class, it can take 5, 10 minutes to actually execute

and record in /var/log/messages.

 

For testing and turnaround, I need immediate.

 

I take it that the above is due to runinterval = <smaller number than 1800, the default>

being needed to be added to the puppetmaster configuration.

 

But even smaller numbers like a few minutes (which don't scale well for lots

of patterns) aren't good.

 

I need a method to immediate-apply.

 

Is there one?

 

[Jo Rhett]

You are being very very vague and unclear with your terms. Reading between the lines, I think these three things answer your questions:

"puppet apply" is used on local policy files and happens instantly.

"puppet agent" gets policy from a puppet server, and happens every $runinterval time

"puppet agent --test" would run from a puppet server but happen instantly (after connecting, receiving catalog, etc…)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ef8a6883-0492-4c49-9c5f-db1a3d19578f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/

[jcbollinger]

On Thursday, November 14, 2013 1:03:43 PM UTC-6, Stuart Cracraft wrote:

When I apply my class, it can take 5, 10 minutes to actually execute

and record in /var/log/messages.

 

For testing and turnaround, I need immediate.

 

I take it that the above is due to runinterval = <smaller number than 1800, the default>

being needed to be added to the puppetmaster configuration.

 

No.  Is Jo said, "puppet apply" immmediately compiles and applies the specified manifest, and any others that are required by the start-point manifest.  If there is a delay there then it is probably because compilation takes a long time.  Although compilation is usually fast, there are things you can do to make it slow.

The 'runinterval' setting is relevant only to 'puppet agent', and even at that it needs to go into the [main] or [agent] configuration section, on the client machine.

 

But even smaller numbers like a few minutes (which don't scale well for lots

of patterns) aren't good.

 

I need a method to immediate-apply.

 

Is there one?

Yes, more or less.  Either "puppet apply" or "puppet agent --onetime --no-daemonize" will do this (or "puppet agent --test", which is a shortcut for the latter plus one or two other options).  In fact, if the agent is not already running then plain "puppet agent" will normally perform its first run immediately.


John

[Stuart Cracraft]

In good shape here. Got everything up and running yesterday and today.

 

My current question I've posted at the main level.

 

I just want to get at the value (exit status and/or standard output) returned from

any arbitrary Unix command puppet would run.

 

So the question is is there a way to get exec's output (all of it) into a variable

and for the exit status.

 

I don't see a way to do that in the cheat sheet, various books, online nor with google.

 

Stuart

[Felix Frank]

Hi,

no, there is not.

And not to come around as overly critical, but if you ponder the use of
such a functionality, chances are that you are designing a manifest that
is not well in tune with puppets strengths and weaknesses (I wouldn't
want to coin definitions of "right" and "wrong" ways, but there are
nuances).

I suggest you open a new thread and explain exactly what you expect
puppet to do and inquire for good patterns to apply.

Generally, for the case of "chaining actions based on the output of an
executed program", it is advisable to write a shell script to do all
this foot work, have puppet deploy it on the agent box and exec the
whole thing in one go.

HTH,
Felix

[jcbollinger]

On Friday, November 15, 2013 1:33:19 PM UTC-6, Stuart Cracraft wrote:

In good shape here. Got everything up and running yesterday and today.

 

My current question I've posted at the main level.

 

I just want to get at the value (exit status and/or standard output) returned from

any arbitrary Unix command puppet would run.

 

So the question is is there a way to get exec's output (all of it) into a variable

and for the exit status.

 

No.  Puppet variables are meaningful only to the puppetmaster, during the catalog compilation process.  By the time you are applying the catalog to the target node (so that an Exec's command is run), catalog compilation is necessarily complete.

As I said, though, you can create a custom fact that executes whatever command you like on the target node -- before catalog compilation -- and returns its output.  It would be slightly trickier, but I think still possible, to capture the output and exit status into separate facts (or even not so tricky if you were willing for Facter to run the command twice).

Alternatively, you can write a custom provider, either for an existing type or for a new, custom one, that captures command output and exit status in Ruby variables, and does whatever you want with them within the scope of applying a resource of the given type.

As Felix observed, your design concept may not be well aligned with Puppet's mode of operation.  Puppet wants to gather up front all the information needed to compute the details of the target configuration, then to compile the chosen configuration details into a compact representation, and finally to update the target node to match the configuration details.


John