Open source Puppet documentation

Providers are back-ends that support specific implementations of a given resource type, particularly for different platforms. Not all resource types have or need providers, but any resource type concerned about portability will likely need them.


The examples on this page use the apt and dpkg package providers, and the examples used are current as of 0.23.0.

Note: Unless you are maintaining existing type and provider code, or the Resource API limitations affect you, you should use the Resource API to create custom resource types, instead of this method.

Declaring providers


The provide method takes three arguments plus a block:
  • The optional :source argument should be a symbol.
There are several kinds of parent classes you can use:
Base provider
A provider can inherit from a base provider, which is never used alone and only exists for other providers to inherit from. Use the full name of the class. For example, all package providers have a common parent class:
  desc "..."
Another provider of the same resource type
A provider of any resource type
# my_module/lib/puppet/provider/glance_api_config/ini_setting.rb
  # set ini_setting as the parent provider
) do
  # implement section as the first part of the namevar
  def section
  def setting
    # implement setting as the second part of the namevar
  # hard code the file path (this allows purging)
  def self.file_path


The first question to ask about a new provider is where it will be functional, which Puppet calls suitable. Unsuitable providers cannot be used to do any work. The suitability test is late-binding, meaning that you can have a resource in your configuration that makes a provider suitable.


In addition to looking for binaries, Puppet can compare Facter facts, test for the existence of a file, check for a feature such as a library, or test whether a given value is true or false. For file existence, truth, or false, call the confine class method with exists, true, or false as the name of the test and your test as the value:
confine :exists => "/etc/debian_release"
To test Facter values, use the name of the fact:
confine :operatingsystem => [:debian, :solaris]
confine :puppetversion => "0.23.0"
To test a feature, as defined in lib/puppet/feature/*.rb, supply the name of the feature. This is preferable to using a confine :true statement that calls Puppet.features because the expression is only evaluated once. Puppet enables the provider if the feature becomes available during a run (for example, if a package is installed during the run).
confine :feature => :posix
confine :feature => :rrd

Using custom features you can delay resource evaluation until the provider becomes suitable. This is a way of informing Puppet that your provider depends on a file being created by Puppet, or a certain fact being set to some value, or it not being set at all.

Default providers

Providers are generally meant to be hidden from the users, allowing them to focus on resource specification rather than implementation details, soPuppet does what it can to choose an appropriate default provider for each resource type.

defaultfor :operatingsystem => :debian
The same fact-matching functionality as confinement is used.
Alternatively, you can supply a regular expression (regex) value to match against a fact value. This is useful, for example, for providers that should only be default for a specific range of operating system versions:
defaultfor :operatingsystemmajrelease => /^[5-7]$/

How providers interact with resources




The transaction is responsible for storing these returned values and deciding which value to send, and it does its work through a PropertyChange instance. It calls sync on each of the properties, which in turn call the setter by default.

You can override that interface as necessary for your resource type.

All providers must define an instances class method that returns a list of provider instances, one for each existing instance of that provider. For example, the dpkg provider should return a provider instance for every package in the dpkg database.

Provider methods

By default, you have to define all of your getter and setter methods. For simple cases, this is sufficient — you just implement the code that does the work for that property. For the more complicated aspects of provider implementation, Puppet has prefetching, resource methods, and flushing. 



Resource methods



Many providers model files or parts of files, so it makes sense to save up all of the writes and do them in one run. Providers that need this functionality can define a flush instance method to do this. The transaction will call this method after all values are synced (which means that the provider should have them all in its @property_hash variable) but before refresh is called on the resource (if appropriate).

Back to top
The email address of the user submitting feedback.
The URL of the page being ranked/rated.