Details
-
New Feature
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
None
-
Coremunity
-
Platform Core KANBAN
-
New Feature
-
Description
Today it is the case that facts are generated prior to a Puppet run, then Puppet makes changes to the system. Because changes are made, it may be the case that the true value of a fact for a system will have changed after the run, but it will not be updated in PuppetDB until the run interval elapses (typically 30 minutes) and the next run begins.
It is becoming common for PuppetDB queries to be used to select nodes based on fact values, for grouping and reporting. In addition, modules like Erik Dalén's puppetdbquery allow the master to build catalogs for node A based on facts about node B. The longer the time window during which node B's PuppetDB facts are out sync with the node's real fact values, the longer it takes for the infrastructure as a whole to converge on a correct, consistent configuration.
Additionally, the intuitive mental model of reading Puppet reports and fact lists in the console is "Puppet submitted a report at time X, therefore I know that the facts shown are valid as of time X". However, this is not true today as described above.
A common customer assumed use case for facts is being able to query facts in real time to validate information about a server. Because of today's limitations, querying facts does not provide real-time data. At best, the data provided is lagging real-time by up to run_interval on each node.
Feature Request
In addition to submitting facts at the beginning of each run, Puppet should submit updated fact values at the end of each run along with the report.