open-sTeam is a platform for cooperative work and cooperative learning developed at the university of paderborn in germany. the platform is being used at http://societyserver.org/ and is being developed further.

During the last CSM workshop we identified the need to have a good way to share the images we use for testing. We have documented the requirements and the current status in this wiki page (we even have a diagram). So analysis is done... it's time for action. The solution should be relatively easy to implement using our portfolio of solutions. Coordinating all the potential users should be easier during Hackweek, specially since I'll be in Nuremberg (and I can physically chase most people ;-) ).

GOAL

Orcas are amazing animals. They are playful, intelligent, great swimmers, and very social. They also love to play with their food, hunting down their prey with advanced strategies - understanding where its prey hides, how it will try to escape, and how to overcome those tactics - and having a lot of fun doing so, before relentlessly tearing it apart, killing it, and eat it. Not necessarily in that order. Oh, and they have the right color scheme. This forces their prey to also improve and adapt more advanced strategies and tactics. In this arms race, both sides evolve and improve: the evolutionary pressure has made cephalopods highly intelligent, adaptable, and resilient. Unfortunately (for them), they are still very tasty. So we should exert more evolutionary pressure on individuals to help them stay alive as a species.

Hypothesis is a python property based testing framework inspired by quickcheck. My goal was to get familiar with the docs and eventually apply the knowledge to the testing of SES products.

Currently we use openQA for the the YaST integration tests. It runs YaST in a VM and controls it via emulating keyboard input. The result is checked by comparing the screenshots. This approach has several disadvantages:

OpenStack is, undoubtedly, a really huge ecosystem of cooperative services. Rally is a benchmarking tool that answers the question: “How does OpenStack work at scale?”. To make this possible, Rally automates and unifies multi-node OpenStack deployment, cloud verification, benchmarking & profiling. Rally does it in a pluggable way, making it possible to check whether OpenStack is going to work well on, say, a 1k-servers installation under high load. Thus it can be used as a basic tool for an OpenStack CI/CD system that would continuously improve its SLA, performance, and stability. <img src="https://wiki.openstack.org/w/images/thumb/e/ee/Rally-Actions.png/850px-Rally-Actions.png" width="700">

Hackweek 18 Update

What Has Been Done During HackWeek 18

Problem statement

Once a kernel is built, a developer/janitor may want to boot the kernel for various reasons, such as performing simple boot test or running tests and workloads from user space or simply playing around in a shell. However, an easy to use and a descriptive tool to perform those tasks doesn't exist to our knowledge.

Currently, the Xen-Project supports automated build-testing/CI via GitLab pipelines, within containers based on: * Debian

kubeojo in 10 seconds-click-me to visualize-demo-link

code:

"salt-toaster" allows you to test multiple Salt package flavors across different operating systems via Docker containers. This project is heavily used on the SUSE Manager team to hardening the Salt package that is shipped on the openSUSE/SLE distributions. Link to GitHub repository The "salt-toaster" execution is divided on different steps (image building, container spinning, salt key acceptance, tests execution, etc) but currently we only get the global results for the entire testsuite execution.

The salt-toaster (https://github.com/openSUSE/salt-toaster) is a tool created and developed by SUSE employees that we've been using for testing Salt since few years ago. This tool uses pytest in combination with Docker containers to allow testing the multiple versions of the Salt codebase and as well as Salt packages across multiple distributions.

The most relaxed testing framework of Kubernetes in the world

This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.

labgrid [0] is an embedded board control python library with a focus on testing, development and general automation. It includes a remote control layer to control boards connected to other hosts. My idea was to use this to be able to test my MediaTek boards remotely.

Testing GUIs is hard: unit tests require a tremendous amount of mocking and often don't capture the exact user input anyway, integration tests on the other hand are difficult to setup as they often require a dedicated infrastructure with virtual machines. libuitest should become something like the image recognition part of openQA: it receives a video or image stream from some source and searches for matches (e.g. button found, sound played). It should also be able to send clicks, key presses, strings, etc. back via an abstract API to a backend.

Project Description

Project aims to create tool for specific situations in which current cucumber testsuite used for Uyuni and SUSE Manager is too complex tool and, otherwise, in which manual testing is just still too much time consuming.

Blog about ScummVM Freeware games of our openSUSE Build Service games project

Status

Project Description

Keeping a consolidated view of a project's progress is a non-trivial endeavor. There are far too many moving parts from its inception, such as planning, issue tracking, development, and testing. All the while one must keep track of some form of metrics to ensure that there's progress, and that the progress is happening in the right direction (or whatever is considered the right direction at the moment).

Project Description

Uyuni is the upstream community project from which the very popular SUSE Manager is derived. It uses its own QE test suite wirtten in Cucumber and Ruby. Currently the Uyuni test suite runs with Ruby 2.5.9 which is EOL since 2021. This is because the most current Ruby version for openSUSE Leap 15.4, which the test suite controller runs on, is still Ruby 2.5.9. Updating the Ruby version allows us to modernize the test suite code base and to use more recent Ruby gems that do not support the old Ruby version anymore.