[RFE] Better Extension/Expiration Management

[sadsfae]

This is an RFE to enhance the handling of extensions, the beginnings of some small tie-ins to JIRA to gather more data to put into QUADS with the result being quads-cli, notifications and Wiki/visual improvements.

This could likely be split up into several enhancements as needed.

1) CLI Enhancements

• Provide a command-set for the following enhancements:
  • quads-cli --ls-extensions
    • lists the ticket number for a current cloud extension if pending

# quads-cli --ls-extensions
cloud50: 696
cloud33: 702

• quads-cli --ls-expirations
  • compares the shortest expiring date across all the hosts in each cloud and prints them to stdout

# quads-cli --ls-expirations
cloud02: 3 days, expires: 2020-11-30 Extension: None
cloud03: 1 day, expires: 2020-11-28 Extension: 22324
cloud04: 7 days, expires 2020-12-04 Extension: None

2) Notifications Enhancements

• quads/tools/notify.py:
  • Enable optional muting of sending message 7,5,3,1 day notifications if an extension is filed already per the populated --ls-extensions but not yet actioned.
  • Include a more appropriate expiration notification, listing the extension ticket number in message otherwise if an extension is filed.

3) Wiki Assignments Visual Enhancements

• Ability to change color to match remaining time for expiring clouds that have not submitted an extension
• Ability to change color to reflect if an extension was filed but the lazy operator has not extended it yet, or perhaps it cannot be extended due to conflicts (either way you'd want to know about it).
  • Cloud summary systems wiki title change

Normal	1 day left, extension filed	3 days left, no extension filed	1 day left, no extension filed
Green	Red (pending operator)	Yellow	Orange

How to Get There - Changes / Components

• (New)quads/tools/jira.py: helper library using the JIRA API. This should be the beginnings of a basic helper framework that might do a lot more later.
  • Some basic method(s) required for filtering/listing sub-task'd issues attached to each --cloud-ticket of active assignments as needed below.

(To be run out of Cron)

• Query the JIRA --cloud-ticket and look for the first sub-tasked issue with a definable label (e.g. EXTENSION) that is not of status: Done and update/record a new field in the Cloud collection for something like extension: 1234
• Check the JIRA extension: associations with every cloud for their Status field, if marked done clear the entry.

(Other modifications)

• quads/tools/create_input.py: query the extension field for every cloud and apply the color codes as described in the RFE under Visual.

• bin/quads-cli: Add new argparse for --ls-expirations, --ls-extensions.

(MongoDB considerations)

• Seed all defined cloud documents with the new extension value unless it can create itself on first population.

[sadsfae]

Bounty points as this should close this as well:

• https://github.com/redhat-performance/quads/issues/3

[kambiz-aghaiepour]

for --ls-extensions, would we want to list the extension requests in full? In other words since we know the ticket number associated with the original request, could we use API calls to find all "sub-tasks" that are of type "extension" and list them all? Or possibly just the active extension requests?

[sadsfae]

for --ls-extensions, would we want to list the extension requests in full? In other words since we know the ticket number associated with the original request, could we use API calls to find all "sub-tasks" that are of type "extension" and list them all? Or possibly just the active extension requests?

Good question, the scope would be to only associate the first, valid extension request for a cloud here. I think there would be only one valid extension request at any given time for any cloud that's nearing expiration. There might be duplicates filed due to user error, but there is always just one actionable JIRA ticket we'd reference for extension.

In this case it'd associate the first sub-tasked JIRA issue that is not status: Done that has the label EXTENSION which is always applied via the extension form. That would ensure the first extension request is the one chosen and ignore the rest.

Because we mark extensions as DONE via JIRA when we execute them subsequent lookups (populated by jira.py cron) would ensure no other extensions are listed given this approach. We would handle duplicates by deleting them as we always do during the course of reviewing the backlog.

I think per your comment the beginnings of quads/tools/jira.py would have the potential to do a lot more later though if we wanted as it pertains to tighter JIRA integration.

[sadsfae]

Update here, the JIRA library is already in the codebase as of:

https://review.gerrithub.io/c/redhat-performance/quads/+/508872

Expanded to handle some initial ticket automation here:

https://review.gerrithub.io/c/redhat-performance/quads/+/508905

[sadsfae]

Some further discussion around this, we should consider an optional ability to alert (via postman.py) when the following conditions are met:

(Notification Scenario: Late extension or Operator Miss)

• An assignment has submitted an extension
• That assignment is up for expiration in a short configurable timeframe (e.g. 48hrs, 72hrs, etc)
• The extension can be extended successfully extended
• Tool Burden: notify.py
• Notification Entities: report_cc in quads.yml

(Notification Scenario: Conflict Detected)

• An extension has been submitted
• There is a conflict detected that would interfere with the extension request
• Tool burden: jira.py
• Notification Entities: report_cc in quads.yml and extension requestor