Project

General

Profile

action #114730

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

Added by geor 2 months ago. Updated about 1 month ago.

Status:
Workable
Priority:
Normal
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.

History

#1 Updated by geor 2 months 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

#2 Updated by coolgw about 2 months ago

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

#3 Updated by JERiveraMoya about 1 month 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.

#4 Updated by geor about 1 month 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.

#5 Updated by JERiveraMoya about 1 month ago

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

Also available in: Atom PDF