Make more sense of openQA test results using AI by livdywan

Description

AI has the potential to help with something many of us spend a lot of time doing which is making sense of openQA logs when a job fails.

User Story

Allison Average has a puzzled look on their face while staring at log files that seem to make little sense. Is this a known issue, something completely new or maybe related to infrastructure changes?

Goals

• Leverage a chat interface to help Allison
• Create a model from scratch based on data from openQA
• Proof of concept for automated analysis of openQA test results

Bonus

• Use AI to suggest solutions to merge conflicts
  • This would need a merge conflict editor that can suggest solving the conflict
• Use image recognition for needles

Resources

• TensorFlow
• open-webui
• openQA instance of openSUSE
• openQA documentation

Timeline

Day 1

• Conversing with open-webui to teach me how to create a model based on openQA test results
  • Asking for example code using TensorFlow in Python
  • Discussing log files to explore what to analyze
  • Drafting a new project called Testimony (based on Implementing a containerized Python action) - the project name was also suggested by the assistant

Day 2

• Using NotebookLLM (Gemini) to produce conversational versions of blog posts
  • Writing openQA tests in Python
  • Developing in distrobox containers
• Researching the possibility of creating a project logo with AI
  • Asking open-webui, persons with prior experience and conducting a web search for advice

Highlights

• I briefly tested compared models to see if they would make me more productive. Between llama, gemma and mistral there was no amazing difference in the results for my case.
• Convincing the chat interface to produce code specific to my use case required very explicit instructions.
• Asking for advice on how to use open-webui itself better was frustratingly unfruitful both in trivial and more advanced regards.
• Documentation on source materials used by LLM's and tools for this purpose seems virtually non-existent - specifically if a logo can be generated based on particular licenses

Outcomes

• Chat interface-supported development is providing good starting points and open-webui being open source is more flexible than Gemini. Although currently some fancy features such as grounding and generated podcasts are missing.
• Allison still has to be very experienced with openQA to use a chat interface for test review. Publicly available system prompts would make that easier, though.

---

Enhance UV openQA helper script by mdonis

Description

A couple months ago an UV openQA helper script was created to help/automate the searching phase inside openQA for a given MU to test. The script searches inside all our openQA job groups (qam-sle) related with a given MU and generates an output suitable to add (copy & paste) inside the update log.

This is still a WIP and could use some enhancements.

Goals

• Move script from bash to python: this would be useful in case we want to include this into MTUI in the future. The script will be separate from MTUI for now. The idea is to have this as a CLI tool using the click library or something similar.
• Add option to look for jobs in other sections inside aggregated updates: right now, when looking for regression tests under aggregated updates for a given MU, the script only looks inside the Core MU job group. This is where most of the regression tests we need are located, but some MUs have their regression tests under the YaST/Containers/Security MU job groups. We should keep the Core MU group as a default, but add an option to be able to look into other job groups under aggregated updates.
• Remove the -a option: this option is used to indicate the update ID and is mandatory right now. This is a bit weird and goes against posix stardards. It was developed this way in order to avoid using positional parameters. This problem should be fixed if we move the script to python.

Some other ideas to consider:

• Look into the QAM dashboard API. This has more info on each MU, could use this to link general openQA build results, whether the related RR is approved or not, etc
• Make it easier to see if there's regression tests for a package in an openQA test build. Check if there's a possibility to search for tests that have the package name in them inside each testsuite.
• Unit testing?

More ideas TBD

Resources

https://github.com/os-autoinst/scripts/blob/master/openqa-search-maintenance-core-jobs

https://confluence.suse.com/display/maintenanceqa/Guide+on+how+to+test+Updates

Post-Hackweek update

All major features were implemented. Unit tests are still in progress, and project will be moved to the SUSE github org once everything's done. https://github.com/mjdonis/oqa-search

---

Learn obs/ibs sync tool by xlai

Description

Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.

Goals

Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.

Resources

• https://github.com/os-autoinst/openqa-trigger-from-obs
• https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads

---

New features in openqa-trigger-from-obs for openQA by jlausuch

Description

Implement new features in openqa-trigger-from-obs to make xml more flexible.

Goals

One of the features to be implemented: - Possibility to define "VERSION" and "ARCH" variables per flavor instead of global.

Resources

https://github.com/os-autoinst/openqa-trigger-from-obs

---

OpenQA Golang api client by hilchev

Description

I would like to make a simple cli tool to communicate with the OpenQA API

Goals

• OpenQA has a ton of information that is hard to get via the UI. A tool like this would make my life easier :)
• Would potentially make it easier in the future to make UI changes without Perl.
• Improve my Golang skills

Resources

• https://go.dev/doc/
• https://openqa.opensuse.org/api

---

Make more sense of openQA test results using AI by livdywan

Description

AI has the potential to help with something many of us spend a lot of time doing which is making sense of openQA logs when a job fails.

User Story

Allison Average has a puzzled look on their face while staring at log files that seem to make little sense. Is this a known issue, something completely new or maybe related to infrastructure changes?

Goals

• Leverage a chat interface to help Allison
• Create a model from scratch based on data from openQA
• Proof of concept for automated analysis of openQA test results

Bonus

• Use AI to suggest solutions to merge conflicts
  • This would need a merge conflict editor that can suggest solving the conflict
• Use image recognition for needles

Resources

• TensorFlow
• open-webui
• openQA instance of openSUSE
• openQA documentation

Timeline

Day 1

• Conversing with open-webui to teach me how to create a model based on openQA test results
  • Asking for example code using TensorFlow in Python
  • Discussing log files to explore what to analyze
  • Drafting a new project called Testimony (based on Implementing a containerized Python action) - the project name was also suggested by the assistant

Day 2

• Using NotebookLLM (Gemini) to produce conversational versions of blog posts
  • Writing openQA tests in Python
  • Developing in distrobox containers
• Researching the possibility of creating a project logo with AI
  • Asking open-webui, persons with prior experience and conducting a web search for advice

Highlights

• I briefly tested compared models to see if they would make me more productive. Between llama, gemma and mistral there was no amazing difference in the results for my case.
• Convincing the chat interface to produce code specific to my use case required very explicit instructions.
• Asking for advice on how to use open-webui itself better was frustratingly unfruitful both in trivial and more advanced regards.
• Documentation on source materials used by LLM's and tools for this purpose seems virtually non-existent - specifically if a logo can be generated based on particular licenses

Outcomes

• Chat interface-supported development is providing good starting points and open-webui being open source is more flexible than Gemini. Although currently some fancy features such as grounding and generated podcasts are missing.
• Allison still has to be very experienced with openQA to use a chat interface for test review. Publicly available system prompts would make that easier, though.

---

Yearly Quality Engineering Ask me Anything - AMA for not-engineering by szarate

Goal

Get a closer look at how developers work on the Engineering team (R & D) of SUSE, and close the collaboration gap between GSI and Engineering

Why?

Santiago can go over different development workflows, and can do a deepdive into how Quality Engineering works (think of my QE Team, the advocates for your customers), The idea of this session is to help open the doors to opportunities for collaboration, and broaden our understanding of SUSE as a whole.

Objectives

• Give $audience a small window on how to get some questions answered either on the spot or within days of how some things at engineering are done
• Give Santiago Zarate from Quality Engineering a look into how $audience sees the engineering departments, and find out possibilities of further collaboration

How?

By running an "Ask me Anything" session, which is a format of a kind of open Q & A session, where participants ask the host multiple questions.

How to make it happen?

I'm happy to help joining a call or we can do it async (online/in person is more fun). Ping me over email-slack and lets make the magic happen!. Doesn't need to be during hackweek, but we gotta kickstart the idea during hackweek ;)

Rules

The rules are simple, the more questions the more fun it will be; while this will be only a window into engineering, it can also be the place to help all of us get to a similar level of understanding of the processes that are behind our respective areas of the organization.

Dynamics

The host will be monitoring the questions on some pre-agreed page, and try to answer to the best of their knowledge, if a question is too difficult or the host doesn't have the answer, he will do his best to provide an answer at a later date.

Atendees are encouraged to add questions beforehand; in the case there aren't any, we would be looking at how Quality Engineering tests new products or performs regression tests

Agenda

• Introduction of Santiago Zarate, Product Owner of Quality Engineering Core team
• Introduction of the Group/Team/Persons interested
• Ice breaker
• AMA time! Add your questions $PAGE
• Looking at QE Workflows: How is
  • A maintenance update being tested before being released to our customers
  • Products in development are tested before making it generally available
• Engineering Opportunity Board

---

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
3. Package management (install, remove, update...)
4. Patching
5. Applying any basic salt state (including a formula)
6. Salt remote commands
7. Bonus point: Java part for product identification, and monitoring enablement
8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

• If you don't have knowledge about some of the steps: ask the team
• If you still don't know what to do: switch to another distribution and keep testing.

This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

Pending

FUSS

FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

https://fuss.bz.it/

Seems to be a Debian 12 derivative, so adding it could be quite easy.

• [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
• [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
• [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
• [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
• [W] Applying any basic salt state (including a formula)
• [W] Salt remote commands
• [ ] Bonus point: Java part for product identification, and monitoring enablement

---

Drag Race - comparative performance testing for pull requests by balanza

Description

«Sophia, a backend developer, submitted a pull request with optimizations for a critical database query. Once she pushed her code, an automated load test ran, comparing her query against the main branch. Moments later, she saw a new comment automatically added to her PR: the comparison results showed reduced execution time and improved efficiency. Smiling, Sophia messaged her team, “Performance gains confirmed!”»

Goals

• To have a convenient and ergonomic framework to describe test scenarios, including environment and seed;
• to compare results from different tests
• to have a GitHub action that executes such tests on a CI environment

Resources

The MVP will be built on top of Preevy and K6.

---

Automated Test Report reviewer by oscar-barrios

Description

In SUMA/Uyuni team we spend a lot of time reviewing test reports, analyzing each of the test cases failing, checking if the test is a flaky test, checking logs, etc.

Goals

Speed up the review by automating some parts through AI, in a way that we can consume some summary of that report that could be meaningful for the reviewer.

Resources

No idea about the resources yet, but we will make use of:

• HTML/JSON Report (text + screenshots)
• The Test Suite Status GithHub board (via API)
• The environment tested (via SSH)
• The test framework code (via files)

---