Project Description

This project is planned as a collection of random changes to the documentation files in order to rid them of cluttered in the content, outdated comments, inconsistent style (minor issues), unused parameters, duplications, etc.

Due to their nature, these issues do not represent the problem for the documentation in terms of the content itself or the building process, and are a natural outcome of the fast-growing body of content. Therefore, occasional deep clean-up is both desired and needed.

These changes are mostly related to the quality and style of the raw files.

The ones that are a good-first-issue listed at the top and are marked with (*).

If you want to contribute, please keep in mind to:

create an issue in github to indicate what you want to work on, to avoid duplication of work
make all changes in small increments
group the changes by the type of change (don't mix the changes that are different in nature)
PRs affecting too many different changes or more than one book will be rejected

Goal for this Hackweek

regular deep clean-up
create an opportunity to contribute to the Uyuni documentation

Issues to work on

1(*) External list

create a list of all external links in the documenattion
check if they are up-to-date
define who creates a request for the external link change

2(*) Architecture parameters

check if all architecture parameters are used; remove unused ones
check for the duplicates

3(*) Existing snippets

review all snippets
are they all used?
if the snippetis used only once - decide if we should keep the snippet in that case, or move it as the direct content to the relevant file
tidy up the snippet if possible (remove comments, check line spacing)

4(*) Quick Start Guide - create as a snippet?

revisit the option of having a snippet that is overarching all books (currently not possible)
if possible, see if Quick Start Guide and Install Guide instructions can be chunked up and relevant pages created from the sequences of shared snippets
if not possible, look into the lowest possible maintenance process of these files (their content overlaps significantly)

5(*) Titles capitalizations

Only first letter needs to be capitalized (master branch only for now)
Check: Chapters, paragraphs, procedures
Work in this order: first fix all page titles and navigation - book by book, then move to chapters, paragraphs and procedures (file by file)

6(*) Comments

check ALL comments, book by book. Most relevant: Client Config Guide, Install and Upgrade Guide, Admin Guide. Use blame command to see when they were added. (If older than 2 years, they are likely candidate to be removed completely.)
check all FIXME comments. Fix them, or delete them.
check all comments with the authors' initials: LB, KE, JC, OM

7 Documentation analysis:

images and tables - create a list, check if they are actually necessary, or they need updating, check for the duplicates, can we come up with the Best Practice?
mark which images are version dependent (thus having priority for updating), and which are more generic

8 - To be added...

No Hackers yet

Join this project Leave this project

Looking for hackers with the skills:

uyuni documentation asciidoc github

This project is part of:

Hack Week 23

Activity

about 2 years ago: ygutierrez liked this project.

about 2 years ago: omaric added keyword "uyuni" to this project.

about 2 years ago: omaric added keyword "documentation" to this project.

about 2 years ago: omaric added keyword "asciidoc" to this project.

about 2 years ago: omaric originated this project.

Comments

Be the first to comment!

Similar Projects

uyuni

Set Up an Ephemeral Uyuni Instance by mbussolotto

Description

To test, check, and verify the latest changes in the master branch, we want to easily set up an ephemeral environment.

Goals

Create an ephemeral environment manually
Create an ephemeral environment automatically

Resources
https://github.com/uyuni-project/uyuni
https://www.uyuni-project.org/uyuni-docs/en/uyuni/index.html

mgr-ansible-ssh - Intelligent, Lightweight CLI for Distributed Remote Execution by deve5h

Description

By the end of Hack Week, the target will be to deliver a minimal functional version 1 (MVP) of a custom command-line tool named mgr-ansible-ssh (a unified wrapper for BOTH ad-hoc shell & playbooks) that allows operators to:

Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
Leverage existing SSH trust relationships without additional setup.
Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
Establish a foundation that can later be extended with advanced features such as logging, grouping, interactive shell mode, safe-command checks, and parallel execution tuning.

The MVP should enable day-to-day operations to efficiently target thousands of machines with a single, consistent interface.

Goals

Primary Goals (MVP):

Build a functional CLI tool (mgr-ansible-ssh) capable of executing shell commands on multiple remote hosts using Ansible Runner. Test the tool across a large distributed environment (1000+ machines) to validate its performance and reliability.

Looking forward to significantly reducing the zypper deployment time across all 351 RMT VM servers in our MLM cluster by eliminating the dependency on the taskomatic service, bringing execution down to a fraction of the current duration. The tool should also support multiple runtime flags, such as:

mgr-ansible-ssh: Remote command execution wrapper using Ansible Runner

Usage: mgr-ansible-ssh [--help] [--version] [--inventory INVENTORY]
                   [--run RUN] [--playbook PLAYBOOK] [--limit LIMIT]
                   [--forks FORKS] [--dry-run] [--no-ansible-output]

Required Arguments
--inventory, -i      Path to Ansible inventory file to use

Any One of the Arguments Is Required
--run, -r            Execute the specified shell command on target hosts
--playbook, -p       Execute the specified Ansible playbook on target hosts

Optional Arguments
--help, -h           Show the help message and exit
--version, -v        Show the version and exit
--limit, -l          Limit execution to specific hosts or groups
--forks, -f          Number of parallel Ansible forks
--dry-run            Run in Ansible check mode (requires -p or --playbook)
--no-ansible-output  Suppress Ansible stdout output

Secondary/Stretched Goals (if time permits):

Add pretty output formatting (success/failure summary per host).
Implement basic logging of executed commands and results.
Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
Package the tool so it can be installed with pip or stored internally.

Resources

Collaboration is welcome from anyone interested in CLI tooling, automation, or distributed systems. Skills that would be particularly valuable include:

Python especially around CLI dev (argparse, click, rich)

Move Uyuni Test Framework from Selenium to Playwright + AI by oscar-barrios

Description

This project aims to migrate the existing Uyuni Test Framework from Selenium to Playwright. The move will improve the stability, speed, and maintainability of our end-to-end tests by leveraging Playwright's modern features. We'll be rewriting the current Selenium code in Ruby to Playwright code in TypeScript, which includes updating the test framework runner, step definitions, and configurations. This is also necessary because we're moving from Cucumber Ruby to CucumberJS.

If you're still curious about the AI in the title, it was just a way to grab your attention. Thanks for your understanding.

Nah, let's be honest AI helped a lot to vibe code a good part of the Ruby methods of the Test framework, moving them to Typescript, along with the migration from Capybara to Playwright. I've been using "Cline" as plugin for WebStorm IDE, using Gemini API behind it.

Goals

Migrate Core tests including Onboarding of clients
Improve test reliabillity: Measure and confirm a significant reduction of flakiness.
Implement a robust framework: Establish a well-structured and reusable Playwright test framework using the CucumberJS

Resources

Enable more features in mcp-server-uyuni by j_renner

Description

I would like to contribute to mcp-server-uyuni, the MCP server for Uyuni / Multi-Linux Manager) exposing additional features as tools. There is lots of relevant features to be found throughout the API, for example:

At the end of the week I managed to enable basic system group operations:

List all system groups visible to the user
Create new system groups
List systems assigned to a group
Add and remove systems from groups

Goals

Set up test environment locally with the MCP server and client + a recent MLM server [DONE]
Identify features and use cases offering a benefit with limited effort required for enablement [DONE]
Create a PR to the repo [DONE]

Resources

Uyuni Saltboot rework by oholecek

Description

When Uyuni switched over to the containerized proxies we had to abandon salt based saltboot infrastructure we had before. Uyuni already had integration with a Cobbler provisioning server and saltboot infra was re-implemented on top of this Cobbler integration.

What was not obvious from the start was that Cobbler, having all it's features, woefully slow when dealing with saltboot size environments. We did some improvements in performance, introduced transactions, and generally tried to make this setup usable. However the underlying slowness remained.

Goals

This project is not something trying to invent new things, it is just finally implementing saltboot infrastructure directly with the Uyuni server core.

Instead of generating grub and pxelinux configurations by Cobbler for all thousands of systems and branches, we will provide a GET access point to retrieve grub or pxelinux file during the boot:

/saltboot/group/grub/$fqdn and similar for systems /saltboot/system/grub/$mac

Next we adapt our tftpd translator to query these points when asked for default or mac based config.

Lastly similar thing needs to be done on our apache server when HTTP UEFI boot is used.

Resources

documentation

Advent of Code: The Diaries by amanzini

Description

It was the Night Before Compile Time ...

Hackweek 25 (December 1-5) perfectly coincides with the first five days of Advent of Code 2025. This project will leverage this overlap to participate in the event in real-time.

To add a layer of challenge and exploration (in the true spirit of Hackweek), the puzzles will be solved using a non-mainstream, modern language like Ruby, D, Crystal, Gleam or Zig.

The primary project intent is not just simply to solve the puzzles, but to exercise result sharing and documentation. I'd create a public-facing repository documenting the process. This involves treating each day's puzzle as a mini-project: solving it, then documenting the solution with detailed write-ups, analysis of the language's performance and ergonomics, and visualizations.

                               |
                             \ ' /
                           -- (*) --
                              >*<
                             >0<@<
                            >>>@<<*
                           >@>*<0<<<
                          >*>>@<<<@<<
                         >@>>0<<<*<<@<
                        >*>>0<<@<<<@<<<
                       >@>>*<<@<>*<<0<*<
         \*/          >0>>*<<@<>0><<*<@<<
     ___\\U//___     >*>>@><0<<*>>@><*<0<<
     |\\ | | \\|    >@>>0<*<0>>@<<0<<<*<@<<
     | \\| | _(UU)_ >((*))_>0><*<0><@<<<0<*<
     |\ \| || / //||.*.*.*.|>>@<<*<<@>><0<<<
     |\\_|_|&&_// ||*.*.*.*|_\\db//_
     """"|'.'.'.|~~|.*.*.*|     ____|_
         |'.'.'.|   ^^^^^^|____|>>>>>>|
         ~~~~~~~~         '""""`------'
------------------------------------------------
This ASCII pic can be found at
https://asciiart.website/art/1831

Goals

Code, Docs, and Memes: An AoC Story

Have fun!
Involve more people, play together
Solve Days 1-5: Successfully solve both parts of the Advent of Code 2025 puzzles for Days 1-5 using the chosen non-mainstream language.
Daily Documentation & Language Review: Publish a detailed write-up for each day. This documentation will include the solution analysis, the chosen algorithm, and specific commentary on the language's ergonomics, performance, and standard library for the given task.

Improve GNOME user documentation infrastructure and content by pkovar

Description

The GNOME user documentation infrastructure has been recently upgraded with a new site running at help.gnome.org. This is an ongoing project with a number of outstanding major issues to be resolved. When these issues are addressed, it will benefit both the upstream community and downstream projects and products consuming the GNOME user docs, including openSUSE.

Goals

Address primarily infrastructure-related issues filed for https://gitlab.gnome.org/Teams/Websites/help.gnome.org/, https://github.com/projectmallard and https://github.com/itstool/itstool projects. Work on contributor guides ported from https://wiki.gnome.org/DocumentationProject.html.

Resources

Docs Navigator MCP: SUSE Edition by mackenzie.techdocs

Description

Docs Navigator MCP: SUSE Edition is an AI-powered documentation navigator that makes finding information across SUSE, Rancher, K3s, and RKE2 documentation effortless. Built as a Model Context Protocol (MCP) server, it enables semantic search, intelligent Q&A, and documentation summarization using 100% open-source AI models (no API keys required!). The project also allows you to bring your own keys from Anthropic and Open AI for parallel processing.

Goals

[ X ] Build functional MCP server with documentation tools
[ X ] Implement semantic search with vector embeddings
[ X ] Create user-friendly web interface
[ X ] Optimize indexing performance (parallel processing)
[ X ] Add SUSE branding and polish UX
[ X ] Stretch Goal: Add more documentation sources
[ X ] Stretch Goal: Implement document change detection for auto-updates

Coming Soon!

Community Feedback: Test with real users and gather improvement suggestions

Resources

Repository: Docs Navigator MCP: SUSE Edition GitHub
UI Demo: Live UI Demo of Docs Navigator MCP: SUSE Edition

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 (including bootstrapping with bootstrap script) and Salt-ssh clients

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

In progress/done for Hack Week 25

Guide

We started writin a Guide: Adding a new client GNU Linux distribution to Uyuni at https://github.com/uyuni-project/uyuni/wiki/Guide:-Adding-a-new-client-GNU-Linux-distribution-to-Uyuni, to make things easier for everyone, specially those not too familiar wht Uyuni or not technical.

openSUSE Leap 16.0

The distribution will all love!

https://en.opensuse.org/openSUSE:Roadmap#DRAFTScheduleforLeap16.0

Curent Status We started last year, it's complete now for Hack Week 25! :-D

[W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file) NOTE: Done, client tools for SLMicro6 are using as those for SLE16.0/openSUSE Leap 16.0 are not available yet
[W] 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)
[W] Package management (install, remove, update...). Works, even reboot requirement detection

github

Is SUSE Trending? Popularity and Developer Sentiment Insight Using Native AI Capabilities by terezacerna

Description

This project aims to explore the popularity and developer sentiment around SUSE and its technologies compared to Red Hat and their technologies. Using publicly available data sources, I will analyze search trends, developer preferences, repository activity, and media presence. The final outcome will be an interactive Power BI dashboard that provides insights into how SUSE is perceived and discussed across the web and among developers.

Goals

Assess the popularity of SUSE products and brand compared to Red Hat using Google Trends.
Analyze developer satisfaction and usage trends from the Stack Overflow Developer Survey.
Use the GitHub API to compare SUSE and Red Hat repositories in terms of stars, forks, contributors, and issue activity.
Perform sentiment analysis on GitHub issue comments to measure community tone and engagement using built-in Copilot capabilities.
Perform sentiment analysis on Reddit comments related to SUSE technologies using built-in Copilot capabilities.
Use Gnews.io to track and compare the volume of news articles mentioning SUSE and Red Hat technologies.
Test the integration of Copilot (AI) within Power BI for enhanced data analysis and visualization.
Deliver a comprehensive Power BI report summarizing findings and insights.
Test the full potential of Power BI, including its AI features and native language Q&A.

Resources

Google Trends: Web scraping for search popularity data
Stack Overflow Developer Survey: For technology popularity and satisfaction comparison
GitHub API: For repository data (stars, forks, contributors, issues, comments).
Gnews.io API: For article volume and mentions analysis.
Reddit: SUSE related topics with comments.

issuefs: FUSE filesystem representing issues (e.g. JIRA) for the use with AI agents code-assistants by llansky3

Description

Creating a FUSE filesystem (issuefs) that mounts issues from various ticketing systems (Github, Jira, Bugzilla, Redmine) as files to your local file system.

And why this is good idea?

User can use favorite command line tools to view and search the tickets from various sources
User can use AI agents capabilities from your favorite IDE or cli to ask question about the issues, project or functionality while providing relevant tickets as context without extra work.
User can use it during development of the new features when you let the AI agent to jump start the solution. The issuefs will give the AI agent the context (AI agents just read few more files) about the bug or requested features. No need for copying and pasting issues to user prompt or by using extra MCP tools to access the issues. These you can still do but this approach is on purpose different.

Goals

Add Github issue support
Proof the concept/approach by apply the approach on itself using Github issues for tracking and development of new features
Add support for Bugzilla and Redmine using this approach in the process of doing it. Record a video of it.
Clean-up and test the implementation and create some documentation
Create a blog post about this approach

Resources

There is a prototype implementation here. This currently sort of works with JIRA only.

The Agentic Rancher Experiment: Do Androids Dream of Electric Cattle? by moio

Rancher is a beast of a codebase. Let's investigate if the new 2025 generation of GitHub Autonomous Coding Agents and Copilot Workspaces can actually tame it.

The Plan

Create a sandbox GitHub Organization, clone in key Rancher repositories, and let the AI loose to see if it can handle real-world enterprise OSS maintenance - or if it just hallucinates new breeds of Kubernetes resources!

Specifically, throw "Agentic Coders" some typical tasks in a complex, long-lived open-source project, such as:

❥ The Grunt Work: generate missing GoDocs, unit tests, and refactorings. Rebase PRs.

❥ The Complex Stuff: fix actual (historical) bugs and feature requests to see if they can traverse the complexity without (too much) human hand-holding.

❥ Hunting Down Gaps: find areas lacking in docs, areas of improvement in code, dependency bumps, and so on.

If time allows, also experiment with Model Context Protocol (MCP) to give agents context on our specific build pipelines and CI/CD logs.

Why?

We know AI can write "Hello World." and also moderately complex programs from a green field. But can it rebase a 3-month-old PR with conflicts in rancher/rancher? I want to find the breaking point of current AI agents to determine if and how they can help us to reduce our technical debt, work faster and better. At the same time, find out about pitfalls and shortcomings.

The CONCLUSION!!!

A State of the Union document was compiled to summarize lessons learned this week. For more gory details, just read on the diary below!