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.