A Python library for PagerDuty.

PagerDuty have started returning new self fields in their responses. These fields self-reference the canonical URI of the resource in the response, e.g.:

{
  [...]
  "self": "https://contoso.pagerduty.com/api/v1/escalation_policies/PABCDEF"
}

This causes obvious problems in pygerduty when the key-values from the response payload are passed to a Container constructor. The problem typically manifests with a stack trace not unlike:

  File "/Users/saj/.pex/install/pygerduty-0.28-py2-none-any.whl.ba6cbb714c785594762b7f0a3df561c0fae3a825/pygerduty-0.28-py2-none-any.whl/pygerduty/__init__.py", line 84, in create
    return self.container(self, **response.get(self.sname, {}))
TypeError: __init__() got multiple values for keyword argument 'self'

Added a unique id to the oncall container which ensures list works with the Collection implemented pagination logic (requires an id).

Removed the overridden show() method which is inconsistent with how show works on other objects (the oncalls endpoint does not support getting a single oncall, as there is no PagerDuty id for them).

Also tested that filtering with oncalls.list() works (for example oncalls.list(schedule_ids=['<id>']).

I also added some tests for the extensions and oncalls objects. I don't think the extensions tests are exhaustive yet, but it's a start. Likely needs more work to ensure create/updating extensions works.

Two pieces of valuable information are not included with an incdient:

1. Whether the summary_details includes a subject or a description
2. The extra data contained in the details log entry

With this small code update, an incident is now aware of both of these items. There are two new methods for incidents:

1. incident.get_detail_log_entry(requester_id) #Returns json of log entry
2. incident.has_subject() # Boolean return, if no subject, than it has details (incident.trigger_summary_data.subject/details)

I was troubleshooting a bug today in our code and noticed that these exceptions are defined in multiple places. I was attempting to catch pygerduty.v2.BadRequest and was getting pygerduty.common.BadRequest instead.

These can all be defined in one place and imported. That way, when you throw the exception it is always an instance of the same class.

Thanks!

Fixes #22.

Please note that this pull request will drop support for Python 2.5.

Tested with:

• CPython 2.6.9
• CPython 2.7.10
• CPython 3.3.6
• CPython 3.4.3

I was forced to add a handful of unit tests to ensure basic functionality across the different runtimes. These tests offer minimal coverage. Tests for paginated responses and writes are missing. The tests that do exist may differ from your house style.

@gmjosack in this diff you will see the following changes:

Format Changes

• Copied the contents of __init__.py into v2.py to allow for second version of the library.
• Moved event methods into its own module and updated imports.

V1-> V2 Changes

• Changed the base path to: https://api.pagerduty.com/. (line 538)
• Added version in the request header. (line 22)
• Removed max number of 403 errors, since in v2 rate limited requests will now return a 429 Too many requests error code instead of 403 Forbidden. They no longer want us to retry a request that returns 403. (line 572)

Changes to come

• Updating tests to reflect new structure -- do you have advice on how to do this as to not disrupt the tests for v1? Perhaps a new directory v2_tests/?
• Removing requester_id and moving this to the header of the request.

I can fetch the escalation Policy correctly however it does not load the rules properly.

u'escalation_rules': <pygerduty.EscalationRulesobjectat0x10b7f21d0>

I try to loop on it and get the following:

Traceback (most recent call last):
  File "./verify.py", line 30, in <module>
    for rule in escalation_policy.escalation_rules:
TypeError: 'EscalationRules' object is not iterable

If I try and print the rules I get back the main escalation policy rather than the rules

print escalation_policy.escalation_rules.__dict__

Manually fetching the escalation policy via curl returns all the information:

TOKEN="YOUR-TOKEN-HERE"
COMPANY="YOUR-COMPANY-NAME-HERE"
curl -H "Content-type: application/json" -H "Authorization: Token token=${TOKEN}" -X GET -G \
    --data-urlencode "include[]=teams" \
    --data-urlencode "query=API Escalation" \
    "https://${COMPANY}.pagerduty.com/api/v1/escalation_policies"

So from what I can tell its having issues converting the rules.

Running v0.29.0

The Exception class IntegrationAPIError() is defined like this:

class IntegrationAPIError(Error):
    def __init__(self, message, event_type):
        self.event_type = event_type
        self.message = message

When raising it IntegrationAPIError() the method PagerDuty.create_event() the parameters were reversed:

if not response["status"] == "success":
    raise IntegrationAPIError(event_type, response["message"])

Should be:

if not response["status"] == "success":
    raise IntegrationAPIError(response["message"], event_type)

This PR simply reverses the order of the parameters when raising the exception.

CC/ @gmjosack

• Removed Entities, since this endpoint no longer exists.
• Added new classes to provide easily readible objects.
• Took requester out of init in events module.

I am new to pygerduty and still exploring.

I have a case were i need to get the event details from a log entry...

I know get_trigger_log_entry() gets me the details but the return i am getting is just <LogEntry: contexts=[], created_at=u'2016-05-02T11:42:42Z', agent=<Container: type=u'service'>, type=u'trigger', id=u'someID', channel=<Container: type=u'email', summary=u'SomeSummary'>>

Is there a way i can completely get this info with pygerduty. The return of incidents.show has the link to the log entry but does not give me the content of it.

Is there an attribute to get this content that I am missing.

Can some one please help me with my requirement. Thanks in advance.

…les they're in. You can find the schedules a particular user is in with api/v1/users/user_id/schedules. This is faster than grabbing all schedules and digging through to find a specific user.

Hi, I'd like to add support of a relatively new API to enable an extension which is temporarily disabled by PagerDuty.

API reference: https://developer.pagerduty.com/api-reference/reference/REST/openapiv3.json/paths/~1extensions~1%7Bid%7D~1enable/post

Minor changes in order to better support multi-threading..

1. External pagination required the Collection.count() method to be updated to support when the base_container is not None (ex: when it is an Incident). This looks like it was probably an accidental oversight, as most other Collection methods already take this into consideration.
2. Pagination in the REST API v2 does not use the /count endpoint anymore. Though empirical evidence suggests they have not removed support for it on the main incidents list, there are multiple documentation/community references that suggest it is no longer supported.
3. Threading-off paginated requests in parallel (note to use one PagerDuty instance per thread) rapidly causes requests to run into HTTPError (429) and/or URLError (timeout), eliciting the need for an exponential-backoff-and-retry loop in order to not prematurely break out from iterator/generator loops.

Need to support Events API v2 (not to be confused with REST API v2). New Events API comes with new Common Event Format payload requirements (PD-CEF). Need to create a Events() implementation to handle the new requirements.

README should also be updated for reference to the PD-CEF & Events API v2 documentation.

For tracking purposes.

The original v1 version of Requester included an additive backoff/retry loop for execute_request(). This logic does not appear to have been ported to the v2 Requester class. Unfortunately, HTTPError(429) and URLError(Timeout) both can raise exceptions that will interrupt an iteration in progress. Because we want to allow uninterrupted iteration over things like Incident.list(), any applicable retries should occur before raising these exceptions.

This retry logic is especially pertinent for multi-threading, as (for example) a parent thread may iterate over incidents, while child threads iterate over log_entries. There should be an expectation that rapid requests from the child, causing HTTP 429, should not raise an exception in the parent thread iterator as it does today.

For tracking purposes.

The v2 REST API no longer officially supports the /count path. Although empirical evidence would suggest it still exists for /incidents/count, there is no documentation supporting this, and plenty of support conversations suggesting otherwise. This is especially true for sub-container elements such as Incident.log_entries

To be v2 compliant, all count() calls should be changed to use the documented total=true parameter on a single paginated request. The use of limit=1 should theoretically allow for the smallest possible request, though some testing on older incidents seems to suggest that this must be limit=2 or higher to avoid HTTP errors.