pingdom::users:
  'SRE PagerDuty':
    contact_targets:
      - email: [email protected]
      - number: 555-123-1212
        countrycode: 1

Notice: /Stage[main]/Pingdom/Pingdom_user[SRE PagerDuty]/contact_targets: contact_targets changed

[{'email' => '[email protected]', 'id' => '2786428', 'severity' => 'HIGH'}, 
{'countrycode' => '1', 'id' => '2786431', 'number' => '555-123-1212', 'severity' => 'HIGH'}] 

to 

'{"email"=>"[email protected]", :severitylevel=>"HIGH"} 
{"number"=>"555-123-1212", "countrycode"=>1, :severitylevel=>"HIGH"}'

Not sure why, as the insync? method deals with the differences seen above.

Doesn't appear to happen with puppet apply. Figures.

I know I saw a way to mask sensitive data. Need to implement this.

It's barely enough to get hiera support. Make it smarter. Needs at least the ability to merge hashes and take parameters.

Consider the following hypothetical construct:

Pingdom_check {
    autofilter => true
}

pingdom_check { "http://${facts['fqdn']}/check":
   type => 'http',
   url  => "http://${facts['fqdn']}/check",
   tags => ['http']
}

This would automatically inject a semi-unique tag (most likely "puppet-#{Digest::SHA1.hexdigest(fqdn)[0..5]}") and a corresponding filter_tags value to increase performance. The above has the same effect as the following, except applied to all pingdom_check resources in the manifest:

$filter_tag = 'puppet-' + sha1('encode', $facts['fqdn'])[0,5]

pingdom_check { "http://${facts['fqdn']}/check":
   type        => 'http',
   url         => "http://${facts['fqdn']}/check",
   tags        => [$filter_tag, 'http'],
   filter_tags => [$filter_tag]
}

Having this as the default would ensure that people get good performance without any effort. The only potential issue is API-enforced tag-length restrictions. Whatever restrictions there are, they have been kept secret, so much testing will need to ensue.

Dunno. For some reason Pingdom implemented this differently for users than they did for checks. The API accepts paused: NO, but doesn't seem set the property. Trying true or false resulted in rejected API calls.

The removal of faraday results in less than awesome logging.

User should have a primary property to manage.

Possibly because no userids are provided. I notice the web UI doesn't save that setting when there's no users assigned. Need to test this, and then reject resource definitions that specify notifywhenbackup but no userids.

Doesn't seem to hurt anything, but wtf. Appears to be a "feature" of the Pingdom API, although I'm not sure what purpose it serves, and I'd prefer it didn't do that.

[update] It only happens when new tags are added: existing tags get their counter increased by one.

As the title says.

Currently, after we create or update a check, we make an additional call to get_check_details in order to update the local copy of the check. However, this is probably unnecessary. Puppet fails or succeeds on the result of the create/update, not by comparing the state of the check variable.

Extra API calls is a bug.

We need to create a mapping similar to contacts -> contactids, but this is more challenging as there isn't a documented API call to get integrations. Probably can check https://github.com/KennethWilke/PingdomLib/ to see how they handle the issue (assuming they do).

Allow a credentials file to be passed. E.g. read credentials in YAML from /etc/pingdom/credentials.yml or similar. This will at least be useful for testing. It might also make it possible for puppet resource pingdom_check to work, and someone might care about that.

Pingdom_check { 
    auth_file => '/etc/pingdom/credentials.yml',
    require   => File['/etc/pingdom/credentials.yml']
}   

Apparently Teams Account is a different level of account, and only this level provides the Teams API and requires the account_email parameter.

Will need to allow for not setting account_email and maybe try to disable Team API if we can detect it's not available.

API always returns severity, which means that unless severity is specified in the manifest, we'll be trying to update this property on every run.

Bug so that people know why integrations aren't implemented.

The code for comparing submitted users to a team naively compares list lengths, which results in Could not evaluate: Unknown user in list, if there is a duplicate user (same name), even though it could continue.

Improve comparison in team.rb

Request:

{
    :host=>"portable-evil.T-mobile.com",
    :paused=>:true,
    :tags=>"http,puppet-managed",
    :additionalurls=>"www.domain1.com;www.domain2.com",
    :auth=>"super:secret",
    :url=>"/status/pingdom.xml",
    :name=>"http://portable-evil.T-mobile.com/status",
    :use_legacy_notifications=>:true,
    :type=>:httpcustom
}

Response:

{"error":{
    "statuscode":400,
    "statusdesc":"Bad Request",
    "errormessage":"Invalid parameter value => additionalurls"
}}

It says parameter value, so I'm presuming that the parameter itself is being accepted. According to the documentation, the value should be a semicolon-separated list of hosts, e.g. host1.domain.com;host2.domain.com, however PingdomLib source code comment suggests that the delimiter is colon. In any case, neither works and results in an HTTP 400 error.

Just a bug so that people are aware of why this isn't currently supported.

We can correctly update severity to LOW, and the correct results are returned when we query the API, but the UI doesn't show the LOW severity targets. This is either due to missing a parameter to control the feature controlled by the checkbox labeled 'Use same alerting regardless of check importance', or an actual bug in the API.

Allow user to specify a set of base tags to be appended to all resources, e.g.

Pingdom_check { 
    base_tags => ['puppet-managed'],
    filter_tags  => ['puppet-managed']
}

pingdom_check { "foo":
    tags => [ 'foo', 'bar'] # actually => ['foo', 'bar', 'puppet-managed']
}

Using these two tags together in the defaults ensures that the module only manages a specific subset of resources.

{"statuscode"=>403, "statusdesc"=>"Forbidden", "errormessage"=>"Forbidden"}

Will probably need to contact Pingdom support to figure this one out.

Someone should do this.

Apparently there's acceptable character filters in place for tags. Trying to set a tag to e.g. $facts['fqdn'] will cause the API call to fail. We need to trap this and raise a meaningful exception.

Unclear as to what constitutes an acceptable character. Will need to investigate.

Investigate.

We only show examples for HIGH, and don't do any validation. Fix this.