Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means:

Now we are lack of using internal wiki page to solve problem. One of the reason is that we don't know if it contain the solution we need, and it's not convenient to search it manually in wiki page. It's much more slower than using google. In one group, we are most likely facing the same problem during work. So keeping the best solution, which we got from searching engine, in internal wiki is an efficiency way to collect standard workflow.

The current Jangouts UI is limiting us when thinking about adding new features. Some examples:

While normally data is passed to linuxrc (including an AutoYaST profile), modern auto-install tools like Ignition from CoreOS support a very interesting method: the QEMU Firmware Config device.

Description

Continue the work on kqlite (Lightweight remote SQLite with high availability and auto failover).

The situation of maintained ansible roles for boring server stuff like setting up a LEMP stack (Linux, nginx, mariadb, php) is dire and I would like to improve that. This project is about creating a handful of ansible roles with focus on

A frame work for automatically analysis the result of the performance test. The tool can be used manully as well as used throught openAPI.

As DBus a main component in Linux user space, in this hackweek I plan to learn more about it.

https://gitlab.com/JanZerebecki/transparency-log-watcher

libvirt+Xen should support the qdisk (qemu) rbd backend, providing native access to block devices hosted on Ceph clusters. Adding this support to the libvirt+Xen toolstack will also improve interoperability with SUSE Enterprise Storage.

A new Puppet Master will be set up for the openSUSE and public SUSE infrastructure. We will need to move the puppet code from the old server to a new Gitlab instance, deploy it to the new box with r10k, and perform syntax, validation and RSpec testing through ci.opensuse.org

This project is about fixing this known Jangouts issue that is reported over and over, since many user experiencing problem with the outgoing WebRTC traffic or with camera authorization can "lurk" what happens in the room without being noticed.

Build and benchmark some smaller SES clusters (2 - 3 nodes) targetted at edge deployments. Evaluate the performance and configurations.

Introduction

Parametrizable formulas is a normal salt module plus some metadata in order to interactively parametrize them. The metadata is used to automatically generate forms that are then injected as pillar data.

The recent glibc 2.33 version recently available in Tumbleweed includes this change:

The goal of my project is to achieve total world domination. == Hell, yeah!

The goal is to learn about Kaggle and Machine Learning.

Use machine learning and natural language processing techniques to analyze the changes made in a project, and classify them in:

We need to package avocado, get it into distro and migrate some of our testsuites from ctcs2. Atm avocado is present in openSUSE:Factory and Backports exist at my home project

Create a prototype of an agent on kvm hosts to control the distributen of master / worker nodes between different kvm hosts. No central control plane should be used - the main design goal should be: as simple as possible :-)

Project Description

Try some things about Docker and Understanding Linux Network Internals

This project aims for enabling FCoE over virtio-net. With that we should be able to run FCoE within a KVM guest, and finally have a 'real' FC host in a KVM guest. This should enable 'real' FC testing, like link failure, multipath operations etc.

Description

I would like to make a simple cli tool to communicate with the OpenQA API

In last hackweek, I implemented a RSA private key parser in kernel: https://github.com/SUSE/hackweek/wiki/RSA-private-key-parser-in-kernel

There is a number of possible improvements to the architecture of SUSE Manager / Salt integration that should be investigated in order to improve the reliability and scalability of the backend:

QA uses a dashboard (SUSE internal: http://qa.suse.de/dashboard/ ) to provide an overview of various data to assess the quality of a product.

This would be a multiple step solution, a first idea that I would explore would be:

Currently, each filesystem developer does his fstests runs (a testsuite for regression-testing of filesystems) on his dedicated test machine, on Orthos machine, ... This not only means duplication of efforts to automate this testing but also leads to inefficient use of resources (sometimes the test machine is just idle, sometimes you would need more tests to run in parallel to speed up development). The goal of this effort is to use SUSE Engineering Cloud to implement fire-and-forget fstests runs where you specify kernel to test (fetched from git tree or so), fstests configs to run, and then just pick up test results later on...