Skip to content

Instantly share code, notes, and snippets.

@mattyjones
Created August 9, 2017 00:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mattyjones/856a1c25a87d74f153d756ecbcfa3559 to your computer and use it in GitHub Desktop.
Save mattyjones/856a1c25a87d74f153d756ecbcfa3559 to your computer and use it in GitHub Desktop.

New Functionality

I am submitting the inital stable version of a pagerduty module that will allow a developer the following functionality:

/users

  • add users
  • update users
  • remove users

/teams

  • add teams
  • update teams
  • remove teams

/users/{id}/contact_methods

  • add a user contact method
  • update a user contact method
  • remove a user contact method

I did this by creating a pagerduty directory under monitoring as an initial place to store these modules. This is done as they all share a common purpose and code which I have placed in module_utils. According to the docs and conversations I have had in IRC, this is allowable and in fact makes sense.

Existing Functionality

There are already two pagerduty modules that do not yet share code with the three I have written but I am in the process of refactoring them to bridge that gap. This will entail a breaking change as they will be renamed to follow my convention of naming after the api endpoint they hit. The first, pagerduty_alert, allows a developer to trigger, acknowledge or resolve a PagerDuty incident. The second, pagerduty, allows a developer to create PagerDuty maintenance windows.

These will be refactored and renamed as necessary.

Design

The three new modules are broken up in such a manner that each is as complete a wrapper of the endpoint it hits as I initially needed. As time goes on and things evolve I have plans to port the services endpoint and possibly the escalation policies endpoint. I can elect myself to be the maintainer of these modules if the community wishes as I am currently running them in production so it is in my personal intreast to ensure they are stable

ToDo

Documentation is nearly complete but I need to update two of the options. Return values are stable but I am unsure if they are correct per community standards. I have not yet written unit tests for these modules but they are on my roadmap for next week. Next to those items I am not sure what else needs to be done to make them stable.

This is my first commit to Ansible and my first time writing a module, for all I know I may be way off base here. Please feel free if anyone is so inclined to tell me I am off my rocker and I will go back to the drawing board and refactor the code as needed. I have read through all the docs for submitting a module and writing a module and I feel this is in a solid, initial stable state. I have been using it for a few weeks now without issue. I can share my roles that implement this as well if the community thinks that will be of value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment