Project Description

Uyuni is the upstream community project from which the very popular SUSE Manager is derived. It uses its own QE test suite wirtten in Cucumber and Ruby. Currently the Uyuni test suite runs with Ruby 2.5.9 which is EOL since 2021. This is because the most current Ruby version for openSUSE Leap 15.4, which the test suite controller runs on, is still Ruby 2.5.9. Updating the Ruby version allows us to modernize the test suite code base and to use more recent Ruby gems that do not support the old Ruby version anymore.

After talking to Lubos about using a more recent Ruby version on Leap 15.4, he recommended to use the ones from devel:languages:ruby built in the OBS.

Goal for this Hackweek

1. Step

update Ruby on the Uyuni test suite controller to version 3.1/3.2
adapt the test suite code to work with the new Ruby version

2. Step

update all used Ruby gems step by step
adapt the test suite code to work with the updated gems. Major ones are Capybara, Cucumber and Selenium Webdriver

Bonus

Fix new RuboCop issues when removing the TODO file

Resources

Skills

Ruby
Selenium/Capybara
Cucumber/BDD
Terraform/sumaform
Salt

Looking for hackers with the skills:

uyuni ruby cucumber gems rubygems rubocop leap capybara selenium terraform sumafrom salt testing qe qa suma susemanager

This project is part of:

Hack Week 22 Hack Week 23

Activity

almost 2 years ago: e_bischoff liked this project.

almost 2 years ago: j_renner liked this project.

almost 2 years ago: admehmood liked this project.

almost 2 years ago: oscar-barrios liked this project.

almost 2 years ago: dgedon added keyword "suma" to this project.

almost 2 years ago: dgedon added keyword "susemanager" to this project.

almost 2 years ago: dgedon started this project.

almost 2 years ago: dgedon added keyword "selenium" to this project.

almost 2 years ago: dgedon added keyword "terraform" to this project.

almost 2 years ago: dgedon added keyword "sumafrom" to this project.

almost 2 years ago: dgedon added keyword "salt" to this project.

almost 2 years ago: dgedon added keyword "testing" to this project.

almost 2 years ago: dgedon added keyword "qe" to this project.

almost 2 years ago: dgedon added keyword "qa" to this project.

almost 2 years ago: dgedon added keyword "uyuni" to this project.

almost 2 years ago: dgedon added keyword "ruby" to this project.

almost 2 years ago: dgedon added keyword "cucumber" to this project.

almost 2 years ago: dgedon added keyword "gems" to this project.

almost 2 years ago: dgedon added keyword "rubygems" to this project.

almost 2 years ago: dgedon added keyword "rubocop" to this project.

almost 2 years ago: dgedon added keyword "leap" to this project.

almost 2 years ago: dgedon added keyword "capybara" to this project.

almost 2 years ago: dgedon originated this project.

Comments

2 months ago by dgedon | Reply

This project is officially done.

Similar Projects

uyuni

Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

Project Description

Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.

In current state the published version can be used only as a Prometheus exporter and missing some of the key features implemented in PoC (not published). Now it can provide metrics related to salt events and state apply process on the minions. But there is no control on this process implemented yet.

Continue with implementation of the missing features and improve the existing implementation:

authentication (need to decide how it should be/or not related to salt auth)
web service providing the control of states deployment

Goal for this Hackweek

Implement missing key features
Implement the tool for state deployment control with CLI

Resources

https://github.com/openSUSE/saline

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):

Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
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)
Package management (install, remove, update...)
Patching
Applying any basic salt state (including a formula)
Salt remote commands
Bonus point: Java part for product identification, and monitoring enablement
Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
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

Run local LLMs with Ollama and explore possible integrations with Uyuni by PSuarezHernandez

Description

Using Ollama you can easily run different LLM models in your local computer. This project is about exploring Ollama, testing different LLMs and try to fine tune them. Also, explore potential ways of integration with Uyuni.

Goals

Explore Ollama
Test different models
Fine tuning
Explore possible integration in Uyuni

Resources

https://ollama.com/
https://huggingface.co/
https://apeatling.com/articles/part-2-building-your-training-data-for-fine-tuning/

Install Uyuni on Kubernetes in cloud-native way by cbosdonnat

Description

For now installing Uyuni on Kubernetes requires running mgradm on a cluster node... which is not what users would do in the Kubernetes world. The idea is to implement an installation based only on helm charts and probably an operator.

Goals

Install Uyuni from Rancher UI.

Resources

mgradm code: https://github.com/uyuni-project/uyuni-tools
Uyuni operator: https://github.com/cbosdo/uyuni-operator

Edge Image Builder and mkosi for Uyuni by oholecek

Description

One part of Uyuni system management tool is ability to build custom images. Currently Uyuni supports only Kiwi image builder.

Kiwi however is not the only image building system out there and with the goal to also become familiar with other systems, this projects aim to add support for Edge Image builder and systemd's mkosi systems.

Goals

Uyuni is able to

provision EIB and mkosi build hosts
build EIB and mkosi images and store them

Resources

Uyuni - https://github.com/uyuni-project/uyuni
Edge Image builder - https://github.com/suse-edge/edge-image-builder
mkosi - https://github.com/systemd/mkosi

ruby

Recipes catalog and calculator in Rails 8 by gfilippetti

My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

TO DO

Index page
Product page
Admin area -- Supplies calculator based on orders -- Orders notification
Authentication
Payment
Deployment

Day 1

As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

Day 2

Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

Hackweek 24

For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

Day 1

Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

Description

"LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

Goals

Goals of this project:

Modify the RSpec tests and run them against a real LDAP server
Replace the net-ldap rubygem with the ruby-ldap rubygem

Achieving the above mentioned goals will:

Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
Make a step towards officially supporting LDAP in OBS.

Resources

Replace ruby-ldap rubygem with net-ldap

cucumber

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

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

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):

Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
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)
Package management (install, remove, update...)
Patching
Applying any basic salt state (including a formula)
Salt remote commands
Bonus point: Java part for product identification, and monitoring enablement
Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
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.

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

leap

New migration tool for Leap by lkocman

Update

I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

Description

SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

Goals

A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

Leap -> Leap n+1 (minor and major version updates)
Leap -> SLES docs
Leap -> Tumbleweed
Leap -> Slowroll
Leap Micro -> Leap Micro n+1 (minor and major version updates)
Leap Micro -> MicroOS

Hackweek 24 update

Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

Repository

https://github.com/openSUSE/opensuse-migration-tool

Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

Resources

Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction

selenium

Selenium with Python by xguo

Description

Try to create test case about Selenium base on Python

Goals

Knowledge about Selenium with Python
Create new test case about Selenium

Resources

https://selenium-python.readthedocs.io/ https://www.selenium.dev/

terraform

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

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

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):

Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
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)
Package management (install, remove, update...)
Patching
Applying any basic salt state (including a formula)
Salt remote commands
Bonus point: Java part for product identification, and monitoring enablement
Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
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.

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

Contribute to terraform-provider-libvirt by pinvernizzi

Description

The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.

It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.

If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.

Goals

Get more familiar with Terraform provider development and libvirt bindings in Go
Solve some issues and/or implement some features
Get in touch with the community around the project

Resources

Rancher/k8s Trouble-Maker by tonyhansen

Project Description

When studying for my RHCSA, I found trouble-maker, which is a program that breaks a Linux OS and requires you to fix it. I want to create something similar for Rancher/k8s that can allow for troubleshooting an unknown environment.

Goal for this Hackweek

Create a basic framework for creating Rancher/k8s cluster lab environments as needed for the Break/Fix Create at least 5 modules that can be applied to the cluster and require troubleshooting

Resources

https://github.com/rancher/terraform-provider-rancher2 https://github.com/rancher/tf-rancher-up

SUSE AI Meets the Game Board by moio

Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!

Results: Infrastructure Achievements

We successfully built and automated a containerized stack to support our AI experiments. This included:

a Fully-Automated, One-Command, GPU-accelerated Kubernetes setup: we created an OpenTofu based script, tofu-tag, to deploy SUSE's RKE2 Kubernetes running on CUDA-enabled nodes in AWS, powered by openSUSE with GPU drivers and gpu-operator
Containerization of the TAG and PyTAG frameworks: TAG (Tabletop AI Games) and PyTAG were patched for seamless deployment in containerized environments. We automated the container image creation process with GitHub Actions. Our forks (PRs upstream upcoming):
- https://github.com/moio/TabletopGames/tree/hackweek24
- https://github.com/moio/PyTAG/tree/hackweek24

./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

Results: Game Design Insights

Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .
- more about Bamboo on Dario's site
- more about R3 on Silvio's site (italian, translation coming)
- more about Totoro on Silvio's site

A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

Results: Learning, Collaboration, and Innovation

Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

"Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

The Context: AI + Board Games

terraform-provider-feilong by e_bischoff

Project Description

People need to test operating systems and applications on s390 platform.

Installation from scratch solutions include:

just deploy and provision manually (with the help of ftpboot script, if you are at SUSE)
use s3270 terminal emulation (used by openQA people?)
use LXC from IBM to start CP commands and analyze the results
use zPXE to do some PXE-alike booting (used by the orthos team?)
use tessia to install from scratch using autoyast
use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
directly install a Linux kernel on a LPAR and use kvm + libvirt from there

Deployment from image solutions include:

use ICIC web interface (openstack in disguise, contributed by IBM)
use ICIC from the openstack terraform provider (used by Rancher QA)
use zvm_ansible to control SMAPI
connect directly to SMAPI low-level socket interface

IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

Goal for Hackweek 23

My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

Goals for Hackweek 24

Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

Let's add support for fiberchannel disks and multipath.

Goals for Hackweek 25

Finish support for fiberchannel disks and multipath
Fix problems with registration on hashicorp providers registry

salt

Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

Project Description

Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.

Continue with implementation of the missing features and improve the existing implementation:

authentication (need to decide how it should be/or not related to salt auth)
web service providing the control of states deployment

Goal for this Hackweek

Implement missing key features
Implement the tool for state deployment control with CLI

Resources

https://github.com/openSUSE/saline

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

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

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):

Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
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)
Package management (install, remove, update...)
Patching
Applying any basic salt state (including a formula)
Salt remote commands
Bonus point: Java part for product identification, and monitoring enablement
Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
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.

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

testing

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

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.

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.

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

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)

Hack on isotest-ng - a rust port of isotovideo (os-autoinst aka testrunner of openQA) by szarate

Description

Some time ago, I managed to convince ByteOtter to hack something that resembles isotovideo but in Rust, not because I believe that Perl is dead, but more because there are certain limitations in the perl code (how it was written), and its always hard to add new functionalities when they are about implementing a new backend, or fixing bugs (Along with people complaining that Perl is dead, and that they don't like it)

In reality, I wanted to see if this could be done, and ByteOtter proved that it could be, while doing an amazing job at hacking a vnc console, and helping me understand better what RuPerl needs to work.

I plan to keep working on this for the next few years, and while I don't aim for feature completion or replacing isotovideo tih isotest-ng (name in progress), I do plan to be able to use it on a daily basis, using specialized tooling with interfaces, instead of reimplementing everything in the backend

Todo

Add make targets for testability, e.g "spawn qemu and type"
Add image search matching algorithm
Add a Null test distribution provider
Add a Perl Test Distribution Provider
Fix unittests https://github.com/os-autoinst/isotest-ng/issues/5
Research OpenTofu how to add new hypervisors/baremetal to OpenTofu
Add an interface to openQA cli

Goals

Implement at least one of the above, prepare proposals for GSoC
Boot a system via it's BMC

Resources

See https://github.com/os-autoinst/isotest-ng

qa

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?

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?

Rules

Dynamics

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

suma

Build Edge Image Builder ISO with SUSE Manager by mweiss2

Description

With SUSE Manager, we can build OS Images using KIWI and container images. As we have Edge Image Builder, we want to see if it is possible to use SUSE Manager to build/customize OS Images by integrating Edge Image Builder as well.

Goals

To make the process easier for customers, a single-build pipeline that automatically adds the combustion and artifact files from the EIB process is desirable.

Kiwi and EIB need to come from a Git Repository.
Kiwi and EIB need to be running as containers.
Configuration options for the images used for Kiwi and EIB build.
X86 and ARM64 Support.
SUSE Manager 4.3 and 5.X Support.
SLES 15 SP6 / SL Micro 6.0 and SL Micro 6.1 Support.

Outcome

Change the Kiwi build process to use Podman with the Kiwi image registry.suse.com/bci/kiwi:10.1.10
Change the Edge Image Builder to produce a combustion-only ISO
Extract the contents and write them to a dedicated /OEM partition integrated via Kiwi into the ISO Kiwi creates.

Sources and PRs

https://github.com/Martin-Weiss/kiwi-image-micro-gpu-60
https://github.com/suse-edge/edge-image-builder/pull/618
https://github.com/uyuni-project/uyuni/pull/9507

susemanager

Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

Project Description

Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.

Continue with implementation of the missing features and improve the existing implementation:

authentication (need to decide how it should be/or not related to salt auth)
web service providing the control of states deployment

Goal for this Hackweek

Implement missing key features
Implement the tool for state deployment control with CLI

Resources

https://github.com/openSUSE/saline

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

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

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):

Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
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)
Package management (install, remove, update...)
Patching
Applying any basic salt state (including a formula)
Salt remote commands
Bonus point: Java part for product identification, and monitoring enablement
Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
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.

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

Create SUSE Manager users from ldap/ad groups by mbrookhuis

Description

This tool is used to create users in SUSE Manager Server based on LDAP/AD groups. For each LDAP/AD group a role within SUSE Manager Server is defined. Also, the tool will check if existing users still have the role they should have, and, if not, it will be corrected. The same for if a user is disabled, it will be enabled again. If a users is not present in the LDAP/AD groups anymore, it will be disabled or deleted, depending on the configuration.

The code is written for Python 3.6 (the default with SLES15.x), but will also work with newer versions. And works against SUSE Manger 4.3 and 5.x

Goals

Create a python and/or golang utility that will manage users in SUSE Manager based on LDAP/AD group-membership. In a configuration file is defined which roles the members of a group will get.

Installation
Usage

Installation

To install this project, perform the following steps:

Be sure that python 3.6 is installed and also the module python3-PyYAML. Also the ldap3 module is needed:

bash zypper in python3 python3-PyYAML pip install yaml

On the server or PC, where it should run, create a directory. On linux, e.g. /opt/sm-ldap-users
Copy all the file to this directory.
Edit the configsm.yaml. All parameters should be entered. Tip: for the ldap information, the best would be to use the same as for SSSD.
Be sure that the file sm-ldap-users.py is executable. It would be good to change the owner to root:root and only root can read and execute:

bash chmod 600 * chmod 700 sm-ldap-users.py chown root:root *

Usage

This is very simple. Once the configsm.yaml contains the correct information, executing the following will do the magic:

bash /sm-ldap-users.py

repository link

https://github.com/mbrookhuis/sm-ldap-users

Improve Development Environment on Uyuni by mbussolotto

Description

Currently create a dev environment on Uyuni might be complicated. The steps are:

add the correct repo
download packages
configure your IDE (checkstyle, format rules, sonarlint....)
setup debug environment
...

The current doc can be improved: some information are hard to be find out, some others are completely missing.

Dev Container might solve this situation.

Goals

Uyuni development in no time:

using VSCode:
- setting.json should contains all settings (for all languages in Uyuni, with all checkstyle rules etc...)
- dev container should contains all dependencies
- setup debug environment
implement a GitHub Workspace solution
re-write documentation

Lots of pieces are already implemented: we need to connect them in a consistent solution.

Resources

https://github.com/uyuni-project/uyuni/wiki

Project Description

Goal for this Hackweek

1. Step

2. Step

Bonus

Resources

Links

Skills

Looking for hackers with the skills:

This project is part of:

Activity

Comments

2 months ago by dgedon | Reply

Similar Projects

Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

Project Description

Goal for this Hackweek

Resources

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Pending

FUSS

Run local LLMs with Ollama and explore possible integrations with Uyuni by PSuarezHernandez

Description

Goals

Resources

Install Uyuni on Kubernetes in cloud-native way by cbosdonnat

Description

Goals

Resources

Edge Image Builder and mkosi for Uyuni by oholecek

Description

Goals

Resources

Recipes catalog and calculator in Rails 8 by gfilippetti

TO DO

Day 1

Day 2

Hackweek 24

Day 1

Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

Description

Goals

Resources

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Pending

FUSS

New migration tool for Leap by lkocman

Update

Description

Goals

Hackweek 24 update

Repository

Resources

Selenium with Python by xguo

Description

Goals

Resources

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Pending

FUSS

Contribute to terraform-provider-libvirt by pinvernizzi

Description

Goals

Resources

Rancher/k8s Trouble-Maker by tonyhansen

Project Description

Goal for this Hackweek

Resources

SUSE AI Meets the Game Board by moio

Results: Infrastructure Achievements

Results: Game Design Insights

Results: Learning, Collaboration, and Innovation

The Context: AI + Board Games

terraform-provider-feilong by e_bischoff

Project Description

Goal for Hackweek 23

Goals for Hackweek 24

Goals for Hackweek 25

Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

Project Description