Configuring automated Puppet runs
Between the on-demand runs you trigger yourself, the Puppet agent runs automatically on a cron schedule. Three properties control when those automated runs happen and how far their start times are spread out.
| Property | Property key | Description |
|---|---|---|
| Cron Puppet Client Hours | my_cron_puppet_client_hours | The hours at which the Puppet agent runs. This property accepts multiple values, so it holds a list of hours rather than a single value, for example 0, 4, 8, 12, 16, 20. |
| Cron Puppet Client Minutes | my_cron_puppet_client_minutes | The minutes at which the Puppet agent runs. This property also accepts multiple values. |
| Puppet Maxwait | my_puppet_maxwait | The maximum random delay, in seconds, before a scheduled run starts. Each scheduled run waits a random time up to this value, which keeps many nodes from contacting the Puppet server at the same moment. If the property is unset or isn't a number, a value of 1800 is used. A value of 0 doesn't mean no delay: on nodes that use RVC Puppet, RVC applies its default random wait of up to 300 seconds instead. To start scheduled runs with effectively no delay, set this property to 1. For more information, see Transitioning from Puppet Launcher to RVC Puppet. |
The hours and minutes values determine the cron schedule that invokes the agent, which is why the schedule is a fixed set of clock times rather than an interval measured from the previous run. A node whose hours are set to 0, 4, 8, 12, 16, 20 runs six times a day at those hours, regardless of when its last run finished.
Where the schedule is defined
All three properties follow the standard property hierarchy, so the schedule can be set at the site, node group, or node level, with the more specific level overriding the broader one. A site-wide default can therefore be overridden for a particular node group, and a node group value can be overridden for an individual node. For an explanation of the hierarchy and how overrides resolve, see Understanding configuration data.
This makes the schedule a targeting tool as well as a setting. You can, for example, give a pilot node group a more frequent schedule than the rest of the fleet so that changes converge there first.
In practice these values are set when your environment is first configured and are rarely changed afterward. If you need to change the schedule, contact SC//Reliant Support or your account manager.
Checking the effective schedule on a node
Because the schedule can be overridden at several levels, read the effective value from the node rather than inferring it from the property settings.
rvc puppet statusThe Next Run At field reports when the next automated run is due. The rvc puppet status command requires RVC 3.13.0 or later.
To see the cron entries on the node directly, on any RVC version, use the following command.
rvc sys crontabThe scheduled entry shows the hours and minutes from the properties, and the --random-wait value from Puppet Maxwait. The form of the entry depends on whether the node uses Puppet Launcher or RVC Puppet. For more information, see Transitioning from Puppet Launcher to RVC Puppet.
Related documentation
- Deploying changes to your environment: triggering a Puppet run on demand instead of waiting for the schedule.
- Transitioning from Puppet Launcher to RVC Puppet: how scheduled runs differ between Puppet Launcher and RVC Puppet.
- Understanding configuration data: the property hierarchy that determines the effective schedule for each node.
- puppet.run: the
rvc puppet runcommand reference, including--random-wait.