Agama installer on-line demo by lslezak

Description

The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.

The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.

The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.

As a proof of concept I already created this on-line demo.

The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).

Goals

• Create an Agama on-line demo which can be easily tested by users
• The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
• Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)

TODO

• Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
• Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
• Fix changing the product, currently it gets stuck after clicking the "Select" button.
• Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
• Allow changing the UI language
• Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
• Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.

Changing the UI language

This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.

Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.

Resources

• Agama sources
• Experimental proof of concept demo
• The respective source code change

---

Design the new UI for storage configuration at Agama by ancorgs

Description

We are in the process of re-designing the web user interface to configure storage at Agama. We expected to have a clear idea of what we wanted before starting Hack Week. But the idea is still not that clear. So I will use use my Hack Week time to try several prototypes since I really want this to be done.

Goals

Have a prototype using Patternfly components and addressing all the use-cases we want to cover. Easy for the easy cases. Capable for the complex ones.

---

Editor mode at Agama web interface by ancorgs

Description

Agama is a new Linux installer that will be very likely used for SLES 16.

It takes a configuration (in JSON format) as input. And offers several interfaces to build that configuration in an easy and interactive way.

I was considering the possibility to add to the web interface a "text editor" mode similar to the XML editor available at virt-manager. That could be used to see how the changes in the UI translate into changes on the configuration.

Goals

• Refresh my knowledge about UI development for Agama, since there was a major overhaul recently (adopting TanStack Query) and I need to learn the new way to do things.
• Please hackers who always want to know how things work internally. :-)

---

Agama Expert Partitioner by joseivanlopez

Description

Agama is a new Linux installer that will be very likely used for SLES 16.

It offers an UI for configuring the target system (language, patterns, network, etc). One of the more complex sections is the storage configuration, which is going to be revamped. This project consists on exploring the possibility of having something similar to the YaST Expert Partitioner for Agama.

Goals

• Explore different approaches for the storage UI in Agama.

---

Try to render Agama in a TUI browser by ancorgs

Description

Agama is a new Linux installer that will be very likely used for SLES 16. It offers a modern and convenient web interface that can be executed both locally and remotely.

But of course some users will miss the old TUI (ncurses) interface of the YaST installer.

So I want to experiment whether would it be possible to render a simplified version of the web interface for TUI browsers. That's only doable and maintainable if we keep the current technology stack we use for rendering the full-blown page, simply replacing complicated UI elements with others that are easy to render. That means the browser would need to support Javascript.

Chawan seems to be almost there regarding support for Javascript, XHR and related technologies. But according to this conversation, the next missing piece would be to support recursive import of module script tags.

Unfortunately, Chawan is written in Nim and I'm pretty sure a week is not enough time for me to learn Nim, implement the feature at Chawan and then fix whatever is the next obstacle on the Agama side.

But if someone could take care of the Nim part, I would do the same with the Agama one. So this is basically a call for help to get this project even started.

---

Small healthcheck tool for Longhorn by mbrookhuis

Project Description

We have often problems (e.g. pods not starting) that are related to PVCs not running, cluster (nodes) not all up or deployments not running or completely running. This all prevents administration activities. Having something that can regular be run to validate the status of the cluster would be helpful, and not as of today do a lot of manual tasks.

As addition (read enough time), we could add changing reservation, adding new disks, etc. --> This didn't made it. But the scripts can easily be adopted.

This tool would decrease troubleshooting time, giving admins rights to the rancher GUI and could be used in automation.

Goal for this Hackweek

At the end we should have a small python tool that is doing a (very) basic health check on nodes, deployments and PVCs. First attempt was to make it in golang, but that was taking to much time.

Overview

This tool will run a simple healthcheck on a kubernetes cluster. It will perform the following actions:

• node check: This will check all nodes, and display the status and the k3s version. If the status of the nodes is not "Ready" (this should be only reported), the cluster will be reported as having problems

• deployment check: This check will list all deployments, and display the number of expected replicas and the used replica. If there are unused replicas this will be displayed. The cluster will be reported as having problems.

• pvc check: This check will list of all pvc's, and display the status and the robustness. If the robustness is not "Healthy", the cluster will be reported as having problems.

If there is a problem registered in the checks, there will be a warning that the cluster is not healthy and the program will exit with 1.

The script has 1 mandatory parameter and that is the kubeconf of the cluster or of a node off the cluster.

The code is writen for Python 3.11, but will also work on 3.6 (the default with SLES15.x). There is a venv present that will contain all needed packages. Also, the script can be run on the cluster itself or any other linux server.

Installation

To install this project, perform the following steps:

• Create the directory /opt/k8s-check

mkdir /opt/k8s-check

• Copy all the file to this directory and make the following changes:

chmod +x k8s-check.py

---

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

---

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/

---

Symbol Relations by hli

Description

There are tools to build function call graphs based on parsing source code, for example, cscope.

This project aims to achieve a similar goal by directly parsing the disasembly (i.e. objdump) of a compiled binary. The assembly code is what the CPU sees, therefore more "direct". This may be useful in certain scenarios, such as gdb/crash debugging.

Detailed description and Demos can be found in the README file:

Supports x86 for now (because my customers only use x86 machines), but support for other architectures can be added easily.

Tested with python3.6

Goals

Any comments are welcome.

Resources

https://github.com/lhb-cafe/SymbolRelations

symrellib.py: mplements the symbol relation graph and the disassembly parser

symrel_tracer*.py: implements tracing (-t option)

symrel.py: "cli parser"

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

Project Description

Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

Done in previous Hackweeks

• Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
• Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

Goal for this Hackweek

The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

Issue list is here: https://github.com/belgaied2/harvester-cli/issues

Resources

The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

• Testing it and creating issues
• Documentation
• Go code improvement

What you might learn

Harvester CLI might be interesting to you if you want to learn more about:

• GitHub Actions
• Harvester as a SUSE Product
• Go programming language
• Kubernetes API

---

Switch software-o-o to parse repomd data by hennevogel

Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org

---