Automate Puppet fact caching management

Automate Puppet fact caching management Gathering facts about your system is an essential part of a Puppet run. Most facts can be fetched very quickly and don’t significantly impact the speed of your Puppet run. However, some facts can take a considerable time to resolve and have a big impact on the time it takes Puppet to run. Since facter version 4, you can cache facts. Facts that take up a lot of time and/or are not very volatile can be cached. Caching of facts is controlled by a configuration file on your system. In this blog post, we show you how you can manage the contents of this configuration file with Puppet.

How it works

The facter.conf file is a configuration file that allows you to cache and block fact groups and facts, and manage how Facter interacts with your system. It contains segments about grouping facts, settings for caching facts, and global settings for facts. Here is the full Puppet documentation. for the content of this file.

A use case.

Let’s say we have a fact that contains the installed patch information about your installed Oracle version. Unfortunately, it takes quite some time to gather this information. Also, this information doesn’t change very often. ( Not every Puppet run or every day). This combination of properties makes this fact an ideal candidate for fact caching.

Enable fact caching

To enable fact caching for the fact `ora_installed_patches’ from within Puppet, you can add this code to your Puppet codebase:

fact_config { 'ora_installed_patches':
  ttl =>  '24 hours'
}

This segment of Puppet code will tell Puppet to add the following line to your facter.conf file.

facts : {
  ttls : [
     { "ora_installed_patches" : 24 hours },
  ]
}

Effectively telling facter to cache the fact ora_installed_patches for 24 hours. See the documentation for this type. for more details.

Invalidating cache

So caching this information is excellent. It speeds up your Puppet run. But If we use Puppet to install or remove a patch, we want to tell facter to invalidate the cache. How do we do that? For caching invalidation, easy_type has the type fact_cache. Here is some code invalidating the ora_installed_patches cache after some patches are installed:

fact_cache {'ora_installed_patches':
  ensure => absent,
  refreshonly => true,
}
Ora_patch<||> ~> Fact_cache['ora_installed_patches']

Let’s look at that in more detail. The fact_cache {'ora_installed_patches': ensure => absent} part, tells Puppet to absent(=remove) the facter cache for fact ora_installed_patches. The refreshonly => true part tells Puppet only to do this when it is notified.

The line Ora_patch<||> ~> Fact_cache['ora_installed_patches'] ensures that every time a Ora_patch is added or removed, the fact_cache ora_installed_patches is notified. Thus completing the sequence of events needed to invalidate the cache.

Where are these facter types defined?

These Puppet custom types are defined in the enterprisemodules-easy_type module. The enterprisemodules-easy_type module is a collection of functions, custom types, and other Puppet goodies we use for all of our commercial modules. You are free to install and use it. Check the documentation on the Puppet forge.

Conclusion

When a fact takes a long time and doesn’t change very often, it is an ideal candidate for fact caching. With our types to manage fact caching, you can easily control this from within Puppet. If you could use a hand, we are here to help. Making good Puppet code is our bread and butter at Enterprise Modules. But besides developing our own modules, we are also helping customers build the best possible Puppet code. Do you think you could need some assistance? Don’t hesitate to contact us at info@enterprisemodules.com or by phone: +31 (0)653 847 326 for some consultancy.

About us

Enterprise modules is the leading developer of enterprise-ready puppet modules for Oracle databases,Oracle WebLogic, and IBM MQ software. Our puppet modules help sysadmins and DBAs to automate the installation, configuration, and management of their databases and application server systems. These modules allow them to make managed, consistent, repeatable, and fast changes to their infrastructure and automatically enforce the consistency.