On Feb 21, 9:21 am, Matt Mencel <m...@techminer.net> wrote:
> The only examples I've seen of timeout have it outside the setcode block. > Can anyone confirm it's behavior depending on whether it's inside or > outside setcode? The docs for it are pretty thin. I can tell you this for sure: 1) the contents of the outer block are executed at the time the fact is installed into Facter, but the contents of the setcode block are not executed until later 2) the contents of the setcode block are executed in a scope that has the same access to the (same) timeout variable that contents of the outer block has On the other hand, I think I do have to retract my original assertion (my apologies). It looks like this variable is specific to each resolution of each fact, and moreover that it should appear outside the setcode block to be effective. As far as I can tell from reading the source code, it makes sense to put these things (and only these) into the outer block of a custom fact definition: 1) invocations of the confine method (optional) 2) setting the value of the timeout variable (optional) 3) invoking the setcode method (required) Timeouts are implemented, by the way, by passing the value of the timeout variable as the argument to Ruby's Timeout.timeout() to control the execution of the setcode block (when it is executed). The default timeout is 0, which I guess lets the block run forever if it is inclined to do so. John -- 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.
