an invention by RBrownSUSE
Right now internal SLE development is still organised & structured around the concept of 'Milestones'. Schedules are defined, deadlines are set, and off we go making Alpha 1, 2, 3, Betas 1, 2, 3, RC's, and so on.
Meanwhile, QA has evolved, and with openQA and other automated tooling we are increasingly testing SLE in a more agile, rolling model, testing every single build as soon as it's produced by OBS, and just paying extra attention to the Milestones with additional manual testing.
But this mismatch is starting to cause some problems. QA more and more are filing bugs in new builds which were introduced since the latest Milestone. Developers cannot use that Milestone to reproduce the bug. Developers can get the latest build, but that takes time and might have introduced new issues which prohibit testing, because there is no 'release gating' to ensure that the latest SLE builds are at least a usable level of quality (they normally are, but there is no guarantees).
This is a particular problem during heavy development periods, where the SLE codebase is often as fast or maybe even a little faster moving than Tumbleweed.
However, this is a problem any openSUSEr knows well.. openSUSE Factory used to be like that, and the solution was Tumbleweed, prohibiting human use of Factory and using openQA not only as an indicator of quality but tying it to an explicit release process so before Repositories and ISOs are published as Tumbleweed.
This Hackweek project will experiment with the concept of adopting & adapting Tumbleweed style release tooling and processes to the SLE codebase. If all goes according to plan, we might end up with a constantly usable repository and set of ISOs that QA, Developers, and potentially maybe even one day external Beta testers can use as a reliable 'last known good' SLE development version, regardless of the age of the latest SLE milestones or the status of the absolutely latest SLE builds.
This project is part of:
Hack Week 14
Activity
Comments
-
over 9 years ago by okurz | Reply
What was achieved
Webpage of TumbleSLE is live on tumblesle.qa
TumbleSLE is following the scheme on our shirts for current hack week, "putting the pieces together". You all certainly know Tumbleweed, the rolling distribution of openSUSE, and you should know SLE, the SUSE Linux Enterprise family. TumbleSLE is currently the always latest good build of SLES based on openQA test results.
How does it work
The script tumblesle-release governing the automatic release process is available from okurz/openqa_review extending my python package "openqa-review" which is already used to support the daily openQA review of SLE products on o.s.d. The script is continuously looking for new builds of SLES and comparing it against the last released TumbleSLE version. If a new build is found that does not introduce any regressions (new tests failed) this build is released as the new version of TumbleSLE.
Richard setup a beautiful webpage on tumblesle.qa which is updated automatically whenever the corresponding gitlab repo is changed.
Technical details of system administration
TumbleSLE is stored and made available on a virtual machine in QA departement with name tumblesle.qa.suse.de. The automatic webpage update on changes in the gitlab repo is done by a cronjob of user wwwrun on this machine. The script tumblesle-release is running as user tumblesle continuously. A cronjob of tumblesle is just making sure the script is still running and restarting if not.
-
over 9 years ago by okurz | Reply
The jekyll sources are updated by
/srv/jekyll-source/.git/hooks/post-mergewhenever the jekyll sources change. rbrown added reading the build number into the webpage generation process by adding an appropriate template call. I calltumblesle-releasenow from a wrapper script with all the parameters in/home/tumblesle/bin/tumblesle-release-server-12sp2-x86_64which calls as a post-release-hookupdate_jekyll.Content of
/home/tumblesle/bin/tumblesle-release-server-12sp2-x86_64:flock -n /tmp/tumblesle_release.lock -c "tumblesle-release --openqa-host http://openqa.suse.de --group-id 25 --product 'Server' --src openqa:/var/lib/openqa/factory/ --match '*SP2*Server*x86_64*' --match-hdd 'SLES-12-SP2-x86_64*' -vvvv --post-release-hook /home/tumblesle/bin/update_jekyll" 2>&1 >> /var/log/tumblesle/tumblesle-release.logContent of
/home/tumblesle/bin/update_jekyll:sudo -u wwwrun /srv/jekyll-source/.git/hooks/post-mergeAdded with
visudo:tumblesle ALL=(wwwrun) NOPASSWD: /srv/jekyll-source/.git/hooks/post-mergeNow, can I better save all those system setup instructions as salt states? ;-)
Similar Projects
Update M2Crypto by mcepl
There are couple of projects I work on, which need my attention and putting them to shape:
Goal for this Hackweek
- Put M2Crypto into better shape (most issues closed, all pull requests processed)
- More fun to learn jujutsu
- Play more with Gemini, how much it help (or not).
- Perhaps, also (just slightly related), help to fix vis to work with LuaJIT, particularly to make vis-lspc working.
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
In progress
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)
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles: https://linux-system-roles.github.io/
Enhance git-sha-verify: A tool to checkout validated git hashes by gpathak
Description
git-sha-verify is a simple shell utility to verify and checkout trusted git commits signed using GPG key. This tool helps ensure that only authorized or validated commit hashes are checked out from a git repository, supporting better code integrity and security within the workflow.
Supports:
- Verifying commit authenticity signed using gpg key
- Checking out trusted commits
Ideal for teams and projects where the integrity of git history is crucial.
Goals
A minimal python code of the shell script exists as a pull request.
The goal of this hackweek is to:
- Add more unit tests
- Make the python code modular
- Add code coverage if possible
Resources
- Link to GitHub Repository: https://github.com/openSUSE/git-sha-verify
Improve chore and screen time doc generator script `wochenplaner` by gniebler
Description
I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.
I named this script wochenplaner and have been using it for a few months now.
It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.
Goals
- Fix chore field separation lines
- Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
- Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.
Resources
tbd (Gitlab repo)
Create a page with all devel:languages:perl packages and their versions by tinita
Description
Perl projects now live in git: https://src.opensuse.org/perl
It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.
I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta
But I never had the time to automate this.
I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).
Goals
- Have a script that updates a central repository (e.g.
https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run) - Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)
Resources