On Tuesday, October 8, 2013 6:08:56 PM UTC-5, Paul Oyston wrote: > > I'm really only wanting an up to date set of facts once the puppet agent > has finished making changes to the system, I'm not wanting to modify the > catalog run process by modifying facter values during the run process. I'm > aware that the facts are evaluated and the manifests compiled at the > beginning of the agent run. > > It's simply a matter of PuppetDB not containing the most up to date facts > once that catalog has been completed. > > In the simplest possible example you might push a fact using pluginsync > that checks if mongo is installed, at the start of the puppet agent run the > fact is pulled in and evaluated to be false. The manifests then go away and > make changes to that node, it installs mongo. The puppet agent then > finishes, if you ran the fact on the system now it would return true, but > the puppet master still contains false because it was only evaluated at the > start. You then can't rely on the PuppetDB information until the puppet > agent runs again which could be another hour from the first run, then > another period of time before other nodes pick up on this new fact value. > > What you explained about using Exec (in actuality I'm querying PuppetDB > using puppetdbquery) is exactly what I'm wanting to do and have nodes > perform actions based on the facts about other nodes stored in PuppetDB. > > As I say though, I've already provided a workaround by having a postrun > script that updates the facts using "puppet facts upload", I just need to > do some additional checking to see if there were actually changes in the > run and then only update the facts if there were changes. > >
I still say you are trying to put the recorded facts to a use for which they were not intended and are not well suited. The recorded facts necessarily capture a snapshot of fact values for the target node, and all you're doing is changing time point for that snapshot. On most machines, most of the time, node facts will be the same after a catalog run as they were before anyway, except for those that change continuously (e.g. uptime*). And that brings me to my next point: to the extent that there is a risk of fact values changing during a Puppet run, you cannot rely on them remaining constant *between* Puppet runs, either. The normal interpretation of the node facts stored in PuppetDB is "these are the facts that informed compilation of the node's latest catalog". What you are describing changes that meaning, which presents a moderate risk given that PuppetDB is primarily an internal service for Puppet. Among other things, you may cause the master occasionally to serve up a stored catalog when it really needed to compile a fresh one. 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
