Few weeks ago whilst analyzing the possibility of using Terraform[1] via terraform-libvirt [2] plugin, I came across Terratest [3], which is an automated testing framework. My initial thoughts have been written here [4] but I'd still like to check out Terratest in more detail.

When all of the SUSE Manager squads switched from SCRUM to a Kanban we lost estimations and therefore also the ability to do predictions. But there are other ways to get insights that are even more reliable, since they are based on anecdotal data. The lead and cycle times of issues are the two most important here. I'd like to extract those two for all of the issue from the spacewalk project and explore how they can be visualized in meaning- and helpful ways.

Create a new generic CUPS wrapper backend /usr/lib/cups/backend/monitor that runs in parallel with the actual backend to monitor it.

There are attempts to solve some kernel deadlock with using lockless printk ringbuffer. The proposed implementation is pretty complex (6 stages, 6 write and 6 read barriers, two buffers, entries linked via list, ...) I have a idea how to make it easier with tracking the state and sequence number in one atomic variable. It might allow to remove the lists and many barriers. It is possible that it will just not work. Let's see.

At SUSE Manager and Uyuni we use right now a set of bash scripts called sumaform-test-runner to run terraform and cucumber, send notifications and store cucumber results. However such scripts are currently hard to maintain and extend, and bash is clearly showing it's limitations when it comes to parsing cucumber results, working with JSON stuff, or using APIs. Besides it forces us to have credentials hardcoded at the main.tf files, which is a huge problem for making a public CI for Uyuni.

Currently, the SUMA test-suite takes about 6 hours to complete, often fails in the first tests, which set up the environment for the rest of the tests, those tests are what we named "core features". To solve this problem we had planned to move from Jenkins Job to a Jenkins Pipeline, having stages to split the test suite into core features, initialize clients, secondary features. So,if one stage fails, the rest of the stages will not be executed.