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

    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)

    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

    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).

    Liz - Prompt autocomplete by ftorchia

    Description

    Liz is the Rancher AI assistant for cluster operations.

    Goals

    We want to help users when sending new messages to Liz, by adding an autocomplete feature to complete their requests based on the context.

    Example:

    • User prompt: "Can you show me the list of p"
    • Autocomplete suggestion: "Can you show me the list of p...od in local cluster?"

    Example:

    • User prompt: "Show me the logs of #rancher-"
    • Chat console: It shows a drop-down widget, next to the # character, with the list of available pod names starting with "rancher-".

    Technical Overview

    1. The AI agent should expose a new ws/autocomplete endpoint to proxy autocomplete messages to the LLM.
    2. The UI extension should be able to display prompt suggestions and allow users to apply the autocomplete to the Prompt via keyboard shortcuts.

    Resources

    GitHub repository

    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources

    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

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

    Day 4