Project

General

Profile

Actions

action #111458

closed

Create a small cli/script to help debugging failures with maintenance updates

Added by geor almost 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-05-23
Due date:
% Done:

0%

Estimated time:

Description

Motivation

We now have responsibility of YaST tests in YaST Maintenance Updates.
This means that we will have to debug failures that could be caused by maintenance updates installed on the systems of those runs.
In order to facilitate with this it would be convenient to have a tool that shows a small overview of the maintenance updates that are applied to a job.

Acceptance criteria

AC1: Given an openQA job id, the script can retrieve incidents IDs filtering by product module.
AC2: The script can query information for those IDs that helps to debugs problems (for instance patchinfo)
AC3: The script should be simple enough, containing a few lines that are easy to maintain.
AC4: Consider how we could filter YaST related updates with the final output (not implementation required).

Suggestion

  • Using the openQA Job ID we should be able to construct the var.json url of the job (eg https://openqa.suse.de/tests/8805896/file/vars.json). We can either parse the .json file to get get the Incident IDs from .*_TEST_ISSUES or from the MAINT_TEST_REPO variables.

  • Script should be able to give us incident ids related to specific products, for example if we are only interested in HPCM_TEST_ISSUES we could filter by HPCM, but also we could also interested on ASMM, so we could specify a comma-separated list HPCM,ASMM. Without filter we should get all of them present in the vars.json.

  • For each Incident ID we should be able to get the patchinfo of the update. Eg for Incident ID 24365 this can be done either via getting the file https://build.suse.de/source/SUSE:Maintenance:24364/patchinfo/_patchinfo , or by scraping https://build.suse.de/package/view_file/SUSE:Maintenance:24365/patchinfo/_patchinfo?expand=1 , or via osc commands. All three methods require a login first.

  • The tool should output a small amount of information for each Incident ID. The patchinfo file may contain more info than needed so it could need additional parsing.

  • Once we have a script easy to maintain for us if we would see that we need more features, we will be in a better position to know what we want exactly and we can consider other existing and more powerful tools in that case, but likely this would be enough for our goal.

  • Perhaps just grep by "yast" is enough but perhaps there are more YaST components or maintained by YaST developers which do not start by "yast". We could figure out or ask them, but we don't need to implement that additional filtering for now.

Actions #1

Updated by geor almost 2 years ago

  • Description updated (diff)
Actions #2

Updated by okurz almost 2 years ago

https://github.com/grisu48/openqa-mon could be a good start for a CLI. Alternatives are openqa-cli or https://github.com/os-autoinst/openQA-python-client/ or just the plain openQA API directly.

Actions #3

Updated by JERiveraMoya almost 2 years ago

  • Subject changed from Create a cli tool that outputs a small summary of an openQA job's maintenance updates to Create a small cli/script to help debugging failures with maintenance updates
  • Description updated (diff)
Actions #4

Updated by geor almost 2 years ago

I am a bit confused as to what AC1 means now.

On another note, concerning suggested implementations, I believe the best approach would be to construct the vars.json url with the required openQA job ID, pipe it to jq to get the Incident IDs, and use osc to get the patchinfo for each of those Incidents. Using osc (zypper in osc) is a good approach to the logging in part, since the user can define their .oscrc config with build.suse.de credentials.

Actions #5

Updated by JERiveraMoya almost 2 years ago

  • Description updated (diff)
Actions #6

Updated by JERiveraMoya almost 2 years ago

Fixed AC1 to reflect that is not needed for now to use api secret to query openqa when we can construct the url for now.

Actions #7

Updated by JERiveraMoya almost 2 years ago

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

Updated by rainerkoenig over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to rainerkoenig
Actions #9

Updated by rainerkoenig over 1 year ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF