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 1 year ago: ygutierrez liked this project.

about 1 year ago: omaric added keyword "uyuni" to this project.

about 1 year ago: omaric added keyword "documentation" to this project.

about 1 year ago: omaric added keyword "asciidoc" to this project.

about 1 year ago: omaric originated this project.

Comments

Be the first to comment!

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

Uyuni developer-centric documentation by deneb_alpha

Description

While we currently have extensive documentation on user-oriented tasks such as adding minions, patching, fine-tuning, etc, there is a notable gap when it comes to centralizing and documenting core functionalities for developers.

The number of functionalities and side tools we have in Uyuni can be overwhelming. It would be nice to have a centralized place with descriptive list of main/core functionalities.

Goals

Create, aggregate and review on the Uyuni wiki a set of resources, focused on developers, that include also some known common problems/troubleshooting.

The documentation will be helpful not only for everyone who is trying to learn the functionalities with all their inner processes like newcomer developers or community enthusiasts, but also for anyone who need a refresh.

Resources

The resources are currently aggregated here: https://github.com/uyuni-project/uyuni/wiki

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

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)

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

documentation

Uyuni developer-centric documentation by deneb_alpha

Description

The number of functionalities and side tools we have in Uyuni can be overwhelming. It would be nice to have a centralized place with descriptive list of main/core functionalities.

Goals

Create, aggregate and review on the Uyuni wiki a set of resources, focused on developers, that include also some known common problems/troubleshooting.

Resources

The resources are currently aggregated here: https://github.com/uyuni-project/uyuni/wiki

ddflare: (Dynamic)DNS management via Cloudflare API in Kubernetes by fgiudici

Description

ddflare is a project started a couple of weeks ago to provide DDNS management using v4 Cloudflare APIs: Cloudflare offers management via APIs and access tokens, so it is possible to register a domain and implement a DynDNS client without any other external service but their API.

Since ddflare allows to set any IP to any domain name, one could manage multiple A and ALIAS domain records. Wouldn't be cool to allow full DNS control from the project and integrate it with your Kubernetes cluster?

Goals

Main goals are:

add containerized image for ddflare
extend ddflare to be able to add and remove DNS records (and not just update existing ones)
add documentation, covering also a sample pod deployment for Kubernetes
write a ddflare Kubernetes operator to enable domain management via Kubernetes resources (using kubebuilder)

Available tasks and improvements tracked on ddflare github.

Resources

https://github.com/fgiudici/ddflare
https://developers.cloudflare.com/api/
https://book.kubebuilder.io

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