Jira Plugin for monsaca-notification

Registered by Haneef Ali

Monasca-notification allows creation of custom plugins which can be used to integrate with well known OPS tools. One of the commonly used tool for issue tracking is JIRA. This blueprint is to capture the implementation of JIRA plugin for monasca-notification

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Haneef Ali
Direction:
Needs approval
Assignee:
Haneef Ali
Definition:
New
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Roland Hochmuth
Completed by
Roland Hochmuth

Related branches

Sprints

Whiteboard

The implementation and configuration of JIRA plugin is similar to other plugins such as Email/HipChat etc. The main issues that needs to be discussed is JIRA workflow.

1) JIRA plugin will create only one issue per alarm_definition. The state transitions are added as comment for that issue with alarm details.

        1) When alarm is created for the issue JIRA plugin does the following
                     a) Check if there is a JIRA issue created for that alarm definition
                     b) If there exists no issue for that alarm definition create a new issue
                     c) Check the status of the issue. If the issue is in RESOLVED or CLOSED state, open it
                     d) Add notification details as new comment for that issue

2) Jira plugin will also support custom formatting as per custom notification formatting plugin.

Issues:

1. RH: Did you really mean to imply that one Alarm would be created per Alarm Definition or Alarm?
    I would expect a JIRA ticket per Alarm not an alarm definition
      HA: Ticket for an ALARM definition and not for ALARM. This takes care of flooding.

2. RH: How to you check if there is a pre-existing JIRA ticket for an alarm? Does the plugin query JIRA on the specific alarm ID or does the plugin store the JIRA ticket ID in a database to be used on subsequent queries?

3. RH: It seems non-intuitive to re-open a closed or resolved ticket in JIRA if one exists for the alarm or alarm definition already. I would have expected a new JIRA ticket being created if the ticket is already in the closed or resolved state.

4. RH: Currently, Monasca does not support grouping of alarms. How are problems like an alarm flood handled? I can't see this plugin being useful if an JIRA ticket is created for every alarm. Note, there is another blueprint for flood supression. See, https://blueprints.launchpad.net/monasca/+spec/monasca-notification-flood-suppression. Also, checkout Prometheus inhibition of alarms at, https://prometheus.io/docs/alerting/alertmanager/#inhibition.

5. RH: How/what fields in the JIRA ticket are populated by the notification.
        HA: The notification is added as comment

6. RH: How is authentication done with JIRA?
               HA: It is similar to EMAIL plugin. Auth information is in notification.yaml file

7. RH: If the alarm returns to the OK state, is the ticket resolved or closed?
                HA. Plugin doesn't resolve or close the ticket.

8. RH: What project is the JIRA ticket associated with?
               HA: It is defined by the notification method type.
                       e.g You create a notification method of type JIRA for the url https://myjira.com/?project=ABC&component=XYC

9. RH: Should the notification details be added to the description or the comment of the JIRA ticket? It says in the description up above that the details of the alarm are added to the comment.
             HA: It can be added, but I used comments

10. RH: What is the full lifecycle of a JIRA ticket with respect to the state transitions that an alarm goes through. For example, what happens when the UNDETERMINED state occurs?
                HA, We don't care about state transition. JIRA ticket is updated with current state of the ALARM when raised

Gerrit topic: https://review.openstack.org/#q,topic:jira-plugin,n,z

Addressed by: https://review.openstack.org/348001
    Add Jira Plugin

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.