On Wednesday, February 5, 2014 3:09:48 AM UTC-6, Ralph Bolton wrote: > > Thank you all for your responses. > > From John's response, I see that I'm going to struggle here. Ultimately, I > am just trying to get some details about the system, and will look into > installing our system info script as part of the OS build. Truthfully > though, it's not doing so much that I couldn't just write it in Ruby and > have it run during the fact gathering stage of the initial puppet run. I > would have liked to avoid this though, as it means the same functionality > will live in two places. I guess one day the binary could just be reporting > facts rather than being the source of truth itself. It's not so terrible to > do this, but it's a shame I can't just integrate Puppet with my world, but > instead have to make the world integrate with puppet. > >
That strikes me as a little overblown. Integrating two systems almost always involves some kind of adaptation. At minimum you need to modify "the world" to include installing Puppet. And if you're relying on your custom binary now, then your world already includes some means for getting it onto systems -- continuing to use that would be *less* change, and if you didn't want to do that then you were planning on changes in that area anyway. > This could all be solved if there was a way to make Puppet re-evaluate > facts either on request during a module's execution, or to have them > evaluated on first use (after all, they are written as "fact name = X, code > to execute to get its value = Y"), or some other means. Does any of this > sound like desirable behaviour or worth taking it up with Puppetlabs for > the future? > > Re-evaluating facts during a catalog run: absolutely not. The stability and self consistency of Puppet catalogs depends on all variables, including facts, to keep the same value. On the other hand, deferred fact evaluation is an interesting idea, but more problematic both to build and to use than you probably suppose. You are not the first to struggle in this area. The original idea for "run stages" involved the agent running several times in succession, once for each applicable stage. That sort of behavior would fit your problem nicely, but alas, the ultimate implementation of run stages went in a completely different direction. Still, it should be possible to build a mechanism for Puppet to trigger a fresh run after the current one is done. John -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7a61569-a0fd-4156-aa7c-dfb5aa292f37%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
