Project

General

Profile

Actions

action #155629

closed

coordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release

coordination #155671: [epic] Better handling of SLE maintenance test review

[spike][timeboxed:6h][qem-dashboard] Order blocked incidents by priority to allow reviewers to focus on higher prio incidents first size:S

Added by okurz 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
Start date:
2024-02-19
Due date:
% Done:

0%

Estimated time:

Description

Motivation

https://smelt.suse.de/overview/#testing shows incidents that are in testing with much more details about incidents than http://dashboard.qam.suse.de/blocked does. As apparently openQA test reviewers are not currently able to review all blocking test failures in time maintenance coordinators asked to better focus on incidents by priority. For this to select the higher prio incidents first the entries on http://dashboard.qam.suse.de/blocked should reflect the incident priority, e.g. order by priority or show the priority value.

Acceptance Criteria

Suggestions


Related issues 1 (0 open1 closed)

Related to openQA Infrastructure - action #156301: [bot-ng] Pipeline failed / KeyError: 'priority' / execution took longer than 4h0m0s secondsResolvedmkittler2024-02-29

Actions
Actions #1

Updated by okurz 2 months ago

  • Parent task set to #155671
Actions #2

Updated by okurz 2 months ago

  • Subject changed from [spike][timeboxed:4h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first
  • Priority changed from Normal to High
  • Target version changed from Tools - Next to Ready
Actions #3

Updated by okurz 2 months ago

  • Subject changed from [spike][timeboxed:6h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first
Actions #4

Updated by okurz 2 months ago

  • Subject changed from [spike][timeboxed:6h] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h][qem-dashboard] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first
  • Description updated (diff)
Actions #5

Updated by livdywan 2 months ago

  • Subject changed from [spike][timeboxed:6h][qem-dashboard] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h][qem-dashboard] Order blocked incidents by priority to allow reviewers to focus on higher prio incidents first size:S
  • Description updated (diff)
  • Status changed from New to Workable
Actions #6

Updated by mkittler 2 months ago

  • Status changed from Workable to In Progress
  • Assignee set to mkittler
Actions #8

Updated by openqa_review 2 months ago

  • Due date set to 2024-03-14

Setting due date based on mean cycle time of SUSE QE Tools

Actions #9

Updated by jbaier_cz 2 months ago · Edited

Could this caused the regression seen in https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/2327744 ?

  File "./qem-bot/bot-ng.py", line 7, in <module>
    main()
  File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/main.py", line 32, in main
    sys.exit(cfg.func(cfg))
  File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/args.py", line 34, in do_aggregate_schedule
    bot = OpenQABot(args)
  File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/openqabot.py", line 24, in __init__
    self.incidents = get_incidents(self.token)
  File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/loader/qem.py", line 41, in get_incidents
    xs.append(Incident(i))
  File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/types/incident.py", line 23, in __init__
    self.priority = incident["priority"]
KeyError: 'priority'
Actions #10

Updated by jbaier_cz about 2 months ago

  • Related to action #156301: [bot-ng] Pipeline failed / KeyError: 'priority' / execution took longer than 4h0m0s seconds added
Actions #11

Updated by mkittler about 2 months ago

  • Status changed from In Progress to Feedback

Handles in the other ticket.

So all PRs are prepared. If they are merged and deployed I'll have a look at whether it actually works. (Maybe there are still some bits missing.)

Actions #12

Updated by hrommel1 about 2 months ago

mkittler wrote in #note-11:

Handles in the other ticket.

So all PRs are prepared. If they are merged and deployed I'll have a look at whether it actually works. (Maybe there are still some bits missing.)

Does this change include the display of the priority from SMELT ?

From my experience it would be helpful to have this because it gives indications on if some updates have (almost) the same priority or if there are large gaps in the priority list.

Actions #13

Updated by mkittler about 2 months ago

I'm not familiar with SMELT myself. Considering you're underlining "display" I assume there are multiple priorities. It is about the priority displayed on the top-right corner of pages like https://smelt.suse.de/incident/23314. In that example that would be 379 at the time I'm writing this comment. I'm not aware of any other priorities an incident might have.

If you are just referring to the word "important" left next to the figure: I think this is called "Rating". It will not be displayed anywhere at this point. I suppose it is computed from the prio. This computation could be done on the dashboard as well and shown somewhere on the "Blocked" page. I suppose that'll be another feature request. If we do this we need to make sure that SMELT and the dashboard agree on how the rating is computed. The SMELT API could also expose the computed value which the dashboard would just show as-is. This would ease keeping things in-line with each other but unless the SMELT API would also expose the background color the dashboard could not show the background color accordingly.

Actions #14

Updated by hrommel1 about 2 months ago

mkittler wrote in #note-13:

I'm not familiar with SMELT myself. Considering you're underlining "display" I assume there are multiple priorities. It is about the priority displayed on the top-right corner of pages like https://smelt.suse.de/incident/23314. In that example that would be 379 at the time I'm writing this comment. I'm not aware of any other priorities an incident might have.

Yes, that is exactly the priority value I mean.

It is displayed as well in the queue display of updates to be tested:
https://smelt.suse.de/overview/#testing (Column "Prio")

If you are just referring to the word "important" left next to the figure: I think this is called "Rating". It will not be displayed anywhere at this point. I suppose it is computed from the prio. This computation could be done on the dashboard as well and shown somewhere on the "Blocked" page. I suppose that'll be another feature request. If we do this we need to make sure that SMELT and the dashboard agree on how the rating is computed. The SMELT API could also expose the computed value which the dashboard would just show as-is. This would ease keeping things in-line with each other but unless the SMELT API would also expose the background color the dashboard could not show the background color accordingly.

The Rating should not be part of this implementation. Currently, we don't plan to have it displayed on https://dashboard.qam.suse.de/blocked

Actions #15

Updated by okurz about 2 months ago

Actions #16

Updated by okurz about 2 months ago · Edited

  • Due date deleted (2024-03-14)
  • Status changed from Feedback to Resolved

merged. http://dashboard.qam.suse.de/blocked now shows incident results ordered by priority and the individual incident results show additional information on the bottom. Now we just have to wait until somebody realizes that older low prio incidents are never reviewed which then no one would have expected :o

Actions

Also available in: Atom PDF