Description
TL;DR: I'd like to have something like this for YaST log.
YaST logs all actions it does into the /var/log/YaST2/y2log file. The log is
very detailed and contains every detail of the YaST run. And that's a
problem! Even a default openSUSE Leap 15.4 installation where you basically
just press Next, Next,... produces about a 13MB log file (uncompressed)
with more than 80k lines! ![]()
Navigating in such log is very difficult, you can see every tiny detail what was done, but it is difficult to find the big picture, why was that happening, what was the goal of that part.
Also some code parts repeat during the installation. For example evaluating the base product is done several times during installation, in the self-update step, when displaying the base product license, when registering the system...
So if you see in the log the base product evaluation you cannot be sure to which
step it belongs, you have to scroll up and down to find it. This also means you
have to start reading the log from the very beginning and go on so you know at
which point you currently are. And that is terrible. ![]()
The Idea
Let's introduce some grouping in the log, to define some structure so you can see what was happening, where it started, where it finished and what was the result.
I got inspired by the GitHub Action log grouping:

See more details in the GitHub documentation.
GitHub Actions do not allow nested groups, only one grouping level is possible. The YaST grouping should allow unlimited nested groups. That should allow easy navigation in the log, you should easily get into the point you are interested in, or the other way round, you could easily know where exactly you are.
Something like this:
▼ Registration step
▶ Enter registration data
▶ Register the system
▶ Register the "SLES-15-SP4" base product
▶ Select modules and extensions
▼ Register modules and extensions
▶ Register "Basesystem" module
▼ Register "Server Applications" module
▶ Contacting SCC
▶ Adding "Pool" repository
▶ Adding "Updates" repository
▶ Register "Desktop Applications" module
...
You can see an example y2log with manually added group markers to get an idea how it could look like.
Improving the YaST Logger
First we need to enhance the YaST logger to add special log markers which will
mark each group. We could use the same tags as GitHub Actions (::group:: and
::endgroup::) logged as usual log messages. This would keep the backward
compatibility with the current log format.
Example code:
log.group "Registering the system" do
registration.register(...)
end
The result of the block would be also the result of the logging group. If the
result is a failure (like false, :abort, Exception) we could display the log
group header in red, maybe with some error icon (
).
Adding Result Data
It would be nice to have some result summary for each group so you not have to go into the details.
log.group "Adding online repositories" do |g|
...
g.details = "added #{repos.size} repositories"
:next
end
This would be displayed like this:
▶ Adding online repositories (added 5 repositories)
Custom Failure Reporting
The predefined error values might not be enough in some cases, allow reporting an error explicitly:
log.group "Adding online repositories" do |g|
...
if ret.empty?
g.failure = true
g.details = "No repository added"
end
:skip
end
This should be displayed in the log view like this (in red)
▶ ⚠️ Adding online repositories (No repository added)
The Log Browser
Of course, the added markers allow to easily find the start and end of a block, but it would be nice to have some browser which would visualize the structure of the log.
Writing a desktop application would not be bad but generating an HTML page with
the structured log would be easier. That will also allow us to easily create
a web service for that so you could upload the log and directly see the result
in the web browser. We could also containerize it so you could easily run it
locally. ![]()
And because YaST is written in Ruby and Ruby is also used for web applications let's write the HTML generator in Ruby.
Goal for this Hackweek
- Add grouping support to the YaST logger
- Use it at some places in YaST (at least in the installation workflow manager so we know where each step starts/end)
- Create a script which can parse a single YaST
y2logfile and render a resulting HTML page - Support multiple YaST runs in the log
- Colorized output (errors in red, ....)
- Display nested log groups, allow expanding/collapsing groups with a ▶button
- Basic filtering (show/hide debug messages)
- Generate a single document HTML (with JS and CSS embedded) for easier sharing the generated document or HTML with separate JS and CSS files
Future Enhancements
- Advanced filtering (component based: show/hide libzypp messages, libyui messages, YaST agents,...)
- Allow reading compressed logs (like
y2log-1.gz) - Allow reading whole tarballs created by
save_y2logscript - Create a web application, instead of running the script allow uploading it to a server running locally and directly display the rendered page
- Extract some high level data from the log as a description of whole process
(
Upgrading from SLES12-SP3 to SLES15-SP4) or to detect some unusual situations (Using custom registration server http://rmt.example.com). This would be displayed at the top as the log summary - Containerize the script and the web application
- Host the web application at some free hosting service
Needed Skills
- Ruby (text parsing and processing, generating HTML, ERB)
- Web Development (HTML, CSS, JavaScript)
- YaST basics (optional, the y2log structure is trivial)
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
Be the first to comment!
Similar Projects
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
RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso
Description
The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.
We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.
This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.
The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.
Goals
The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.
Key goals for the week:
- Analyze & Identify: Dive into the
SUSE/rmtRuby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions). - Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
- Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like
rb-sysormagnus. - Benchmark: Create a benchmarking script (e.g., using
k6,ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients. - Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.
Resources
- RMT Source Code (Ruby):
https://github.com/SUSE/rmt
- RMT Documentation:
https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
- Tooling & Stacks:
- RMT/Ruby development environment (for running the base RMT)
- Rust development environment (
rustup,cargo)
- Potential Integration Libraries:
- rb-sys:
https://github.com/oxidize-rb/rb-sys - Magnus:
https://github.com/matsadler/magnus
- rb-sys:
- Benchmarking Tools:
k6(https://k6.io/)ab(ApacheBench)
Kudos aka openSUSE Recognition Platform by lkocman
Description
Relevant blog post at news-o-o
I started the Kudos application shortly after Leap 16.0 to create a simple, friendly way to recognize people for their work and contributions to openSUSE. There’s so much more to our community than just submitting requests in OBS or gitea we have translations (not only in Weblate), wiki edits, forum and social media moderation, infrastructure maintenance, booth participation, talks, manual testing, openQA test suites, and more!
Goals
Kudos under github.com/openSUSE/kudos with build previews aka netlify
Have a kudos.opensuse.org instance running in production
Build an easy-to-contribute recognition platform for the openSUSE communit a place where everyone can send and receive appreciation for their work, across all areas of contribution.
In the future, we could even explore reward options such as vouchers for t-shirts or other community swag, small tokens of appreciation to make recognition more tangible.
Resources
(Do not create new badge requests during hackweek, unless you'll make the badge during hackweek)
- Source code: openSUSE/kudos
- Badges: openSUSE/kudos-badges
- Issue tracker: kudos/issues text text