1
votes

I know how to create custom facts normally with .rb files.

But I'm having a problem with the timeline:

> Puppet agent checks-in
> Custom facts are created
> .pp files start to run
> in .pp file I update settings
> TODO based on these new settings update custom fact

We want the puppet facts to represent the system after the .pp file is run.

In my experience I can access a node's facts from the .pp this leads me to think the facts are gathered before the .pp is applied.

Does facter update the facts before ending the check-in process as well?

Would it be possible to set a fact from the .pp file?

Note: I'll be accessing these fact values from puppet agent not puppet server.

3

3 Answers

2
votes

We want the puppet facts to represent the system after the .pp file is run.

They will -- the next time Facter is run after your catalog is applied.

In my experience I can access a node's facts from the .pp this leads me to think the facts are gathered before the .pp is applied.

Facts are gathered before manifest evaluation even begins. This way they are usable during the catalog building process.

Does facter update the facts before ending the check-in process as well?

  • Fact implementations are updated on the target node first of all.
  • Then Facter is run to gather fact values, and the results are submitted to the catalog builder as part of a catalog request.
  • The catalog builder -- often running on an altogether different computer -- then constructs a catalog of target-machine resources based on the manifests (.pp files), submitted fact values, and recorded site data. The facts are available for use during the catalog-building process.
  • The resulting catalog describes the target state of the machine; it is input for the final stage of the run, in which the target machine is updated as necessary to match the catalog. The catalog may contain data drawn from fact values, but it does not reference facts by name.

Would it be possible to set a fact from the .pp file?

You can set variables in manifest files, including at top scope. These are then accessible to inform and direct the catalog building process, and they can be incorporated into resources, such as to form part of the name or content of a file. They are not accessible as variables outside of catalog building.

You can also declare resources via your manifest files that provide the implementations of external facts. In this way, you can provide for customization of the facts that will be reported by future Facter runs, but you cannot add to or alter the facts informing the current catalog run.

Note: I'll be accessing these fact values from puppet agent not puppet server.

You can run Facter directly, on any machine where Puppet is installed, to obtain some or all of that machine's current facts, but that is outside the scope of catalog building. The facts that inform the catalog-building process are all gathered immediately before the catalog request.

0
votes

I found one solution which seems to be to execute facter manually from the puppet file:

exec { 'update puppet facts':
  path    => ['/bin','/usr/bin'],
  command => 'facter',
}

Based on a snippet from Learning Puppet 4: A Guide to Configuration Management and Automation.

0
votes

Since Puppet 5.5.18 you can set resubmit_facts=true in your puppet.conf which will make the agent update facts in PuppetDB also after the run.

You can read more about it in PUP-5934.