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. On Tuesday, 8 October 2013 20:27:34 UTC+1, jcbollinger wrote: > > > > On Tuesday, October 8, 2013 4:31:17 AM UTC-5, Paul Oyston wrote: >> >> Hi Wolf, >> >> Thanks for that diagram, that's incredibly helpful. >> >> It seems a bit of an oversight not to allow facts to be updated during >> the manifest phase since manifests are making changes to the system and >> therefore potentially modifying facts during their run. >> > > > You need to better understand the operational model. Puppet evaluates the > manifests provided to it in light of a target node identity and a set of > facts to compute, all in advance, details of the desired state of the > target node. The result is packaged in a compiled form -- a catalog -- and > handed off to the client-side Puppet runtime for those computed state > details to be ensured. > > Puppet uses fact values only during catalog compilation, before it changes > anything about the target node. They can be interpolated into resource > properties, such as file names or content, but their identity is thereby > lost. Changing or setting fact values in PuppetDB during catalog > application will not have any effect on the catalog application process, > except that in principle you could apply Exec resources that perform > PuppetDB queries and do something dependent on the result. > > > >> I might look into modifying the agent run so that facts can be updated >> during the manifest phase using a custom function of some description. >> > > > Puppet functions run during catalog compilation, not during catalog > application, so that particular approach wouldn't work. Even if you could > make it work, you could not thereby modify the catalog run during catalog > application. > > These are not the hooks you're looking for. > > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
