Home

Deployment notes

It's important to keep in mind that this module manages some resources that aren't node-related (Pingdom_team, Pingdom_user, and Pingdom_settings). This means that, while it may seem logical to put your Pingdom_users in some base class and and then have your Pingdom_checks require those users, you don't want to do this. If you put your Pingdom_users or Pingdom_teams in a common class, then every node will hit the Pingdom API on every run to update these resources. It's a waste of time and bandwidth, especially since these resources will change infrequently.

Pingdom_check and Pingdom_team will autorequire the relevant resources (e.g. users and teams), but these will be soft requirements. That is, if the requirements are available in the catalog, they will be realized first, but if they aren't in the catalog, no failure will be generated. So long as the users exist in Pingdom, the run will succeed. The autorequires are only used for determining order.

With this in mind, it is preferable to manage Pingdom_teams and Pingdom_users on a single system (maybe the Puppet master or a utility system) and only manage Pingdom_checks on each node.