OpenSUSE support for OpenStack Training Labs

Adding opensuse support for OpenSack training labs should be a good idea as this section of the project is going to mature soon and be used world wide for training. Please go through the following link http://git.openstack.org/cgit/openstack/training-guides/tree/labs

Looking for hackers with the skills:

bash opensuse autoyast virtualbox kvm

This project is part of:

Hack Week 11

Activity

  • over 9 years ago: michael-chang liked this project.
  • over 9 years ago: LaiChihsun liked this project.
  • about 11 years ago: rsimai liked this project.
  • about 11 years ago: jsuchome liked this project.
  • about 11 years ago: mjura liked this project.
  • about 11 years ago: bmwiedemann liked this project.
  • about 11 years ago: dguitarbite added keyword "kvm" to this project.
  • about 11 years ago: dguitarbite added keyword "virtualbox" to this project.
  • about 11 years ago: dguitarbite added keyword "autoyast" to this project.
  • about 11 years ago: dguitarbite added keyword "opensuse" to this project.
  • about 11 years ago: dguitarbite added keyword "bash" to this project.
  • about 11 years ago: dguitarbite started this project.
  • about 11 years ago: dguitarbite originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

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

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

    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


    SUSE Health Check Tools by roseswe

    SUSE HC Tools Overview

    A collection of tools written in Bash or Go 1.24++ to make life easier with handling of a bunch of tar.xz balls created by supportconfig.

    Background: For SUSE HC we receive a bunch of supportconfig tar balls to check them for misconfiguration, areas for improvement or future changes.

    Main focus on these HC are High Availability (pacemaker), SLES itself and SAP workloads, esp. around the SUSE best practices.

    Goals

    • Overall improvement of the tools
    • Adding new collectors
    • Add support for SLES16

    Resources

    csv2xls* example.sh go.mod listprodids.txt sumtext* trails.go README.md csv2xls.go exceltest.go go.sum m.sh* sumtext.go vercheck.py* config.ini csvfiles/ getrpm* listprodids* rpmdate.sh* sumxls* verdriver* credtest.go example.py getrpm.go listprodids.go sccfixer.sh* sumxls.go verdriver.go

    docollall.sh* extracthtml.go gethostnamectl* go.sum numastat.go cpuvul* extractcluster.go firmwarebug* gethostnamectl.go m.sh* numastattest.go cpuvul.go extracthtml* firmwarebug.go go.mod numastat* xtr_cib.sh*

    $ getrpm -r pacemaker >> Product ID: 2795 (SUSE Linux Enterprise Server for SAP Applications 15 SP7 x86_64), RPM Name: +--------------+----------------------------+--------+--------------+--------------------+ | Package Name | Version | Arch | Release | Repository | +--------------+----------------------------+--------+--------------+--------------------+ | pacemaker | 2.1.10+20250718.fdf796ebc8 | x86_64 | 150700.3.3.1 | sle-ha/15.7/x86_64 | | pacemaker | 2.1.9+20250410.471584e6a2 | x86_64 | 150700.1.9 | sle-ha/15.7/x86_64 | +--------------+----------------------------+--------+--------------+--------------------+ Total packages found: 2


    OS self documentation, health check and troubleshooting by roseswe

    Project Description

    The aim of this hackweek project is to improve the utility "cfg2html" so that it is even more usable under SLES and perhaps also under Rancher.

    cfg2html (see also https://github.com/cfg2html/cfg2html) itself is a very mature utility for collecting and documenting information of an operating system like Linux, AIX, HP-UX and others.

    Goal for this Hackweek

    The aim is to extend cfg2html

    • for SLES and SLES-for-SAP apps, high availability
    • Improve code for MicroOS 5.x, SUMA, Edge and k8s environments
    • fix shellbeauity warnings
    • possibly add more plugins
    • SUMA/Salt integration to collect.

    Resources

    Required skills: Bash, shell script and the SUSE products mentioned.

    https://github.com/cfg2html/cfg2html

    https://www.cfg2html.com/


    VimGolf Station by emiler

    Description

    VimGolf is a challenge game where the goal is to edit a given piece of text into a desired final form using as few keystrokes as possible in Vim.

    Some time ago, I built a rough portable station using a Raspberry Pi and a spare monitor. It was initially used to play VimGolf at the office and later repurposed for publicity at several events. This project aims to create a more robust version of that station and provide the necessary scripts and Ansible playbooks to make configuring your own VimGolf station easy.

    Goals

    • Refactor old existing scripts
    • Implement challenge selecion
    • Load external configuration files
    • Create Ansible playbooks
    • Publish on GitHub

    Resources

    • https://www.vimgolf.com/
    • https://github.com/dstein64/vimgolf
    • https://github.com/igrigorik/vimgolf


    Create openSUSE images for Arm and RISC-V boards by avicenzi

    Project Description

    Create openSUSE images (or test generic EFI images) for Arm and RISC-V boards that are not yet supported.

    Goal for Hackweek

    Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

    Consider generic EFI images where possible, as some boards can hold a bootloader.

    Document in the openSUSE Wiki how to flash and use the image for a given board.

    Hack Week 25

    Hack Week 24

    Hack Week 23

    Hack Week 22

    Hack Week 21

    Resources


    SUSE KVM Best Practices - Focus on SAP Workloads and Use Cases by roseswe

    Description

    SUSE Best Practices around KVM, especially for SAP workloads. Early Google presentation already made from various customer projects and SUSE sources.

    Goals

    • Complete presentation we can reuse in SUSE Consulting projects
    • 2025: Bring it to version 1.00 ready for customers

    Resources

    KVM (virt-manager) images

    SUSE/SAP/KVM Best Practices

    • https://documentation.suse.com/en-us/sles/15-SP6/single-html/SLES-virtualization/
    • SAP Note 1522993 - "Linux: SAP on SUSE KVM - Kernel-based Virtual Machine" && 2284516 - SAP HANA virtualized on SUSE Linux Enterprise hypervisors https://me.sap.com/notes/2284516
    • SUSECon24: [TUTORIAL-1253] Virtualizing SAP workloads with SUSE KVM || https://youtu.be/PTkpRVpX2PM
    • SUSE Best Practices for SAP HANA on KVM - https://documentation.suse.com/sbp/sap-15/html/SBP-SLES4SAP-HANAonKVM-SLES15SP4/index.html


    A CLI for Harvester by mohamed.belgaied

    Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

    Project Description

    Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

    asciicast

    Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

    Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

    Done in previous Hackweeks

    • Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
    • Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

    Goal for this Hackweek

    The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

    Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

    Issue list is here: https://github.com/belgaied2/harvester-cli/issues

    Resources

    The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

    • Testing it and creating issues
    • Documentation
    • Go code improvement

    What you might learn

    Harvester CLI might be interesting to you if you want to learn more about:

    • GitHub Actions
    • Harvester as a SUSE Product
    • Go programming language
    • Kubernetes API
    • Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)


    Reassess HiFive Premier P550 board (for RISC-V virtualization) by a_faerber

    Description

    With growing interest in the RISC-V instruction set architecture, we need to re-evaluate ways of building packages for it:

    Currently openSUSE OBS is using x86_64 build workers, using QEMU userspace-level (syscall) emulation inside KVM VMs. Occasionally this setup causes build failures, due to timing differences or incomplete emulation. Andreas Schwab and others have collected workarounds in projects like openSUSE:Factory:RISCV to deal with some of those issues.

    Ideally we would be using native riscv64 KVM VMs instead. This requires CPUs with the H extension. Two generally available development boards feature the ESWIN 7700X System-on-Chip with SiFive P550 CPUs, HiFive Premier P550 and Milk-V Megrez. We've had access to the HiFive Premier P550 for some time now, but the early version (based on Yocto) had issues with the bootloader, and reportedly later boards were booting to a dracut emergency shell for lack of block device drivers.

    Goals

    • Update the boot firmware
    • Test whether and how far openSUSE Tumbleweed boots

    Results

    • Boot firmware image 2025.11.00 successfully flashed onto board
      • Enables UEFI boot in U-Boot by default
      • U-Boot's embedded Flat Device Tree is lacking a timebase-frequency, required for recent (6.16.3) mainline kernels (panic leading to reset, visible via earlycon=sbi)
    • Tested eswin/eic7700-hifive-premier-p550.dtb from Ubuntu 2025.11.00 image
      • Allows to boot past the above panic, but times out in JeOS image while waiting for block device, dropping to dracut emergency shell
      • No devices shown in lsblk -- 6.16 appears to be lacking device drivers still

    Resources