Project

General

Profile

Actions

action #114730

closed

[Timebox: 16h] Investigate which job results block approval from qam-openqa review group

Added by geor over 1 year ago. Updated 8 months ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Target version:
-
Start date:
2022-07-27
Due date:
% Done:

0%

Estimated time:

Description

Motivation

When a job from our aggregate maintenance updates fails, it blocks all the related maintenance updates from approval by the members of the qam-openqa group (maintenance openqa reviewers).
The questions arises, what job states, other than failed, result in maintenance updates being blocked?
Does for instance an incomplete job or a cancelled job also block their related updates?
Knowing this will help us better organize the required actions in the context of our Maintenance Update Review process.

Acceptance criteria

AC1 Figure out what job results block update approval for qam-openqa

Suggestions

The maintenance openqa reviewer use this dashboard http://dashboard.qam.suse.de/blocked to have visibility on the blocked updates.
The maintainer of this dashboard (maybe someone from qe-tools?) should be able to help.
Also we could check what happen when some arch doesn't run any job.

Actions #1

Updated by geor over 1 year ago

  • Subject changed from [Timebox: 16h] Investigate what blocks approval from qam-openqa review group to [Timebox: 16h] Investigate which job results block approval from qam-openqa review group
Actions #2

Updated by coolgw over 1 year ago

I suppose if no specific fail on case, no block will happen on maintenance updates

Actions #3

Updated by JERiveraMoya over 1 year ago

I would suggest to modify AC2, because when fails in that way we don't have notification, and the only condition why we accept to do this daily review of MUs is that the notification system will help us, so we don't need to check the group if there is no notification, the agreement is that it would not be on-demand.
We could update the doc saying that 'if by chance we notice this' we can do A,B,C. wdyt?

Additional AC3 could reflect that we should file a ticket to tools teams to cover this enhancement in openQA notifications.

Actions #4

Updated by geor over 1 year ago

JERiveraMoya wrote:

I would suggest to modify AC2, because when fails in that way we don't have notification, and the only condition why we accept to do this daily review of MUs is that the notification system will help us, so we don't need to check the group if there is no notification, the agreement is that it would not be on-demand.
We could update the doc saying that 'if by chance we notice this' we can do A,B,C. wdyt?

Additional AC3 could reflect that we should file a ticket to tools teams to cover this enhancement in openQA notifications.

I agree with both your points, please edit the ticket freely to reflect those.

Actions #5

Updated by JERiveraMoya over 1 year ago

  • Tags deleted (qe-yast-refinement)
  • Description updated (diff)
  • Status changed from New to Workable
Actions #6

Updated by JERiveraMoya over 1 year ago

  • Priority changed from Normal to Low
  • Target version deleted (Current)
Actions #7

Updated by JERiveraMoya 10 months ago

  • Status changed from Workable to New
Actions #8

Updated by JERiveraMoya 8 months ago

  • Status changed from New to Rejected

old ticket, we have solid procedures in YaM squad to avoid this blocking.

Actions

Also available in: Atom PDF