Two questions about custom facts

[Peter Berghold]

First:  I notice in the documentation you can have facts in ${module_path}/lib and in ${module_path}/facts.d.  What is the difference between the two?

Second:  A module that I am writing as I type this is going to have some custom facts to keep a system auditor I work with happy.  It "detects" the existence of a package being installed along with the version if it is installed.  Since the primary reason for the module is to install and configure the package and from my understanding facts run before other stuff is there a way to trigger a redo of the fact?

In other words:

Before puppet run:

              my-packge-installed = false

              my-package-version = null

<puppet runs>

              my-package-installed = true

              my-package-version = 0.5.0

I hope this makes some sort of sense. 

--

Peter L. Berghold                       Salty....@gmail.com

http://science-fiction.berghold.net

[Raphink]

Native facts (written in Ruby using the Facter module) go into lib/facter/, while custom facts (either static text files or scripts in the language of your choice) go into facts.d/.

Facts are computed before each Puppet run. If Puppet installs a package and your fact returns the version of that package, then the fact value will be available after the second Puppet run.

Cheers,

Raphaël

[Peter Berghold]

On Tue, Feb 17, 2015 at 11:31 AM, Raphink <rap...@gmail.com> wrote:

Facts are computed before each Puppet run. If Puppet installs a package and your fact returns the version of that package, then the fact value will be available after the second Puppet run.

OK that's what I suspected.  So there is now way to get the facts to run again during the Puppet run I would take it. <darn!> 

[jcbollinger]

On Tuesday, February 17, 2015 at 1:13:13 PM UTC-6, Salty Old Cowdawg wrote:

On Tue, Feb 17, 2015 at 11:31 AM, Raphink <rap...@gmail.com> wrote:

Facts are computed before each Puppet run. If Puppet installs a package and your fact returns the version of that package, then the fact value will be available after the second Puppet run.

OK that's what I suspected.  So there is now way to get the facts to run again during the Puppet run I would take it. <darn!> 

The fact values relevant to any given catalog run describe the state of the target machine immediately prior to its corresponding catalog request.  This reflects the Puppet operational cycle:

1. The agent syncs plugins with the master.
2. The agent collects fact values (including for any custom facts it just synced).
3. The agent submits a catalog request to the master, including all its computed fact values
4. The master builds a catalog for the requester, based on its identity and facts.  All fact references in manifests and Hiera data are resolved to their corresponding values as part of this process.
5. The master provides the complete catalog to the agent.  There are no fact references in the catalog, though there may be data derived from fact values.
6. The agent applies the catalog, which may involve additional communication with the master to retrieve the content of 'source'd files.

Always keep in mind how coarse-grained this interaction is.  Generally speaking, your modules need to be able to compute the desired target state from a machine's *initial* state, not from some intermediate state occurring transiently during catalog application.  Moreover, no Puppet variable, including fact variables, can take a different value once its value is first set.  These characteristics may be constraining in some ways, but it they are essential for consistent catalogs.


John