TumbleSLE - Applying Tumbleweed Logic to the SLE codebase for more efficient testing & development
an invention by RBrownSUSE
Updated over 6 years ago. 10 hacker ♥️.

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.

Looking for hackers with the skills:

python perl

This project is part of:

Hack Week 14

Activity

  • over 9 years ago: cseader liked this project.
  • over 9 years ago: okurz liked this project.
  • over 9 years ago: okurz joined this project.
  • over 9 years ago: benediktg liked this project.
  • over 9 years ago: fcrozat liked this project.
  • over 9 years ago: digitaltomm liked this project.
  • over 9 years ago: sebchlad liked this project.
  • over 9 years ago: dmaiocchi liked this project.
  • over 9 years ago: osukup liked this project.
  • over 9 years ago: evshmarnev liked this project.
  • over 9 years ago: RBrownSUSE liked this project.
  • over 9 years ago: RBrownSUSE added keyword "python" to this project.
  • over 9 years ago: RBrownSUSE added keyword "perl" to this project.
  • over 9 years ago: RBrownSUSE started this project.
  • over 9 years ago: RBrownSUSE originated this project.


    • Comments

    • okurz
      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.

    • okurz
      over 9 years ago by okurz | Reply

      The jekyll sources are updated by /srv/jekyll-source/.git/hooks/post-merge whenever the jekyll sources change. rbrown added reading the build number into the webpage generation process by adding an appropriate template call. I call tumblesle-release now from a wrapper script with all the parameters in /home/tumblesle/bin/tumblesle-release-server-12sp2-x86_64 which calls as a post-release-hook update_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.log

      Content of /home/tumblesle/bin/update_jekyll:

      sudo -u wwwrun /srv/jekyll-source/.git/hooks/post-merge

      Added with visudo:

      tumblesle ALL=(wwwrun) NOPASSWD: /srv/jekyll-source/.git/hooks/post-merge

      Now, can I better save all those system setup instructions as salt states? ;-)

    Similar Projects

    HTTP API for nftables by crameleon

    Background

    The idea originated in https://progress.opensuse.org/issues/164060 and is about building RESTful API which translates authorized HTTP requests to operations in nftables, possibly utilizing libnftables-json(5).

    Originally, I started developing such an interface in Go, utilizing https://github.com/google/nftables. The conversion of string networks to nftables set elements was problematic (unfortunately no record of details), and I started a second attempt in Python, which made interaction much simpler thanks to native nftables Python bindings.

    Goals

    1. Find and track the issue with google/nftables
    2. Revisit and polish the Go or Python code (prefer Go, but possibly depends on implementing missing functionality), primarily the server component
    3. Finish functionality to interact with nftables sets (retrieving and updating elements), which are of interest for the originating issue
    4. Align test suite
    5. Packaging

    Resources

    • https://git.netfilter.org/nftables/tree/py/src/nftables.py
    • https://git.com.de/Georg/nftables-http-api (to be moved to GitHub)
    • https://build.opensuse.org/package/show/home:crameleon:containers/pytest-nftables-container

    Results

    • Go nftables issue was related to set elements needing to be added with different start and end addresses - coincidentally, this was recently discovered by someone else, who added a useful helper function for this: https://github.com/google/nftables/pull/342.

    Side results

    Upon starting to unify the structure and implementing more functionality, missing JSON output support was noticed for some subcommands in libnftables. I am submitting patches as needed:

    • https://lore.kernel.org/netfilter-devel/20251203131736.4036382-2-georg@syscid.com/T/#u

    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:

    First meeting Hackweek catchup

    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:

    • DONE: Add more unit tests
      • New and more tests can be added later
    • Make the python code modular
    • DONE: Add code coverage if possible

    Resources

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

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. 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)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. 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

    Debian 13

    The new version of the beloved Debian GNU/Linux OS

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [ ] 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)
    • [ ] Package management (install, remove, update...)
    • [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). Probably not for Debian as IIRC we don't support patches yet.
    • [ ] 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)

    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

    Results

    Day 1

    Day 2

    • HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
    • Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-devel-languages-perl-meta
    • I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
    • Tests
      • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
      • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

    Day 3

    • Added various things to the table
      • Dependencies column
      • Show popup with info for cpanspec, patches and dependencies
      • Added last date / commit to the data export.

    Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

    MCP Perl SDK by kraih

    Description

    We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!

    Goals

    • Support for Resources
    • All response types (Audio, Resource Links, Embedded Resources...)
    • Tool/Prompt/Resource update notifications
    • Dynamic Tool/Prompt/Resource lists
    • New authentication mechanisms

    Resources