Description

Create a tool which will make it possible to monitor the lifecycle of pods in a kubernetes cluster (as well as other types of tabular or structured data), and provide a convenient user interface for viewing and interpreting that data. This will be useful in development and testing of our kubernetes-based container platform (Cloud Application Platform), as it will allow us to better understand where things are going wrong when we encounter component failures.

GitLab provides a bridge to connect to Gitter using an IRC client.

Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

I tried to work blockchain into this, just so we could cover the trifecta of buzz words. Sadly I could not maintain saintly and do this.

Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week.

We currently maintain all drivers in the SUSE kernel tree. While this is a well-established procedure, it also has a number of drawbacks in my opinion. I've been experimenting with a different model, tracking (so far, only one) driver in a separate git repository, and packaging it as kernel module package (KMP). This way of working fits my own mental model of code development better than the quilt style we employ in day-to-day driver maintenance.

The goal is to find a way for developing and simple testing an IONIC based multiplatform app with REST API on openSUSE. The focus is to find a way to secure token handling for SSO.

I'm hearing impaired. Where others have no issues following talks or dicussions, I often fail even grasp the bottom line what it's about. I've got hearing aids, but they help only so much. I also have an add-on device for my hearing aids that acts like a bluetooth headset. Unfortunately, making this thing work under my Linux desktop has been an ongoing, frustrating struggle. On the contrary, it works flawlessly with Android devices of different generations, and even with my lowly Gigaset phone. Actually, the thing works better with older kernels/Linux versions than with current TW.

ABF is a buildsystem developed by ROSA (rosalab.com) and OpenMandriva (https://www.openmandriva.org/) currently being used for their distribution.

Take the oportunity to learn Kubernetes, to play with AWS and compare performance and availability of openQA and OBS instances and openSUSE Mirrors running on AWS.

Debian

I got a Raspberry pi 4 not long ago, I'd like to install openSUSE Leap 15.2(Alpha) on it, and set up hass - Home Assistant, a open source home automation assistant on rpi4, then have some fun with it!

The Gameshell is a small game console based on AllWinner R16 (Cortex-A7, IIRC the same CPU that the RPi2). Currently is supporting Debian, and some community member ported ArchLinux on it.

Many cases are Client-Server testing or Multi-Machine testing in FIPS area, I plan to hack and learn more deeply about Multi-Machine test automation in openQA.

Create DevOps automation for testing PTFs prior to delivering to customers, that will be available to each of the team members using standard L3 tools.

Investigate possibilities for the distributed builds for Ceph to speed up builds.

Learn and use tools to build/deploy SUSE/openSUSE to the KVM environment for developing kernel CVE patches and testing automation

I started 3 years ago creating a CNC, but soon last past 6 monts I realized that I could use it as a 3D printer. The software was good enough, the hardware and firmware had evolved. And now I could print 200x200x300 pieces with 0.1mm precision.

Solid Ground is an essential software tool for the daily tasks of an L3 agent. A continuous integration/continuous delivery (CI/CD), and even more a continuous deployment, approach is currently missing from its development ecosystem slowing down its release cycles.

Put together a collection of ideas and resources to mentor people managers on how to make better decisions:

Diagnosing issues with stalling desktop application (or a whole desktop environment) is difficult these days as the application often requires multiple processes interconnected with sockets, pipes, futexes, etc. to work and often it is not clear which process is the one responsible for blocking the whole ecosystem. The idea of this project is to write a tool that gathers information about processes in the system and for each process that is sleeping display the resource (file, socket, futex) it is waiting on as well as the process that is likely responsible for unblocking (feeding pipe, sending data to socket, unlock futex, ...). Once the information is gathered, we can also plot it for graphical displaying with tools like graphviz.

This issue has been blocked for a while due to time constraints so I want to take Hackweek 19 to work on it.

Currently AWS uses a SMT solver to decide on public/non-public policies https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/

Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour.

transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology.

The idea is to hack os-autoinst-distri-opensuse infrastucture and explore design patterns that can fit. The end point of this is to restructure the framework in such a way that the main-common.pm is more efficient, functional and readable.

Once more mailprocessing has developed some bitrot, namely this recent crash:

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.

Motivation

For years we have been discussing the idea to modularize SUSE Manager. This would enable developers to create their own extensions to SUSE Manager without needing to touch the core repository.

Salt is moving towards a plugable architecture using POP and Idem. This project is about experimenting with those new concepts by applying them to a real life case: the virt execution and state modules.

Thinking about extending the typical Twitter app that let's a user bulk-delete their tweets (with a limit of 3200 each time).

Why is it nice?

Learn the inner workings of TCP as implemented in the Linux kernel. This will involve

It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing.

Problem description

This is kinda continuation of my last hackweek project - learning python3 the parcical way. The goal is again to replace existing bash script which will generate 3 node KVM HA cluster on my workstation and automate quite a boring part of HA regression testing.

Since SUSE Manager doesn't scale out and stacking it into another pyramid of susemanagers won't help here, the real architectural changes needs to be done to achieve true scale-out of this product. This hackweek project is about how to Turn SUSE Manager into a cluster.

Last hackweek filtra was created – a tool to extract information like lead and cycle times from Github repos for (but not limited to) projects that are doing Kanban. The collected metrics can then be visualized with Grafana.

Features I'd like to implement:

I own a 3D printer / Anet AM8 / and after 1,5y its time to upgrade the electronics, mainly the stock motherboard and get it ready for multi-color printing. Also the time has come where I would like to not only download 3D models from thingiverse but also create or customize the models for my usage.

The project aims to port openSUSE to the ROCKPro64.

I'd like a way to have a device on my desk which lights up to indicate that I have something I should be paying attention to. Initially, I'd like this to be for Office365 calendar events and GitHub mentions, but ideally it should support arbitrary messages. The plan is to assign specific colors (ideally "patterns" consisting of a sequence of colors and time) to specific message types.

Although CNCF projects are almost exclusively related to Linux containers, some ideas, like wrapping all the services into network proxies to create a distributed data-plane and enable true observability, could perhaps be explored for some kind of backport in complex legacy distributed systems, like... say... S4/HANA?!

Currently we have two sponsored 3D printers available in the Nuremberg office. Both are located in a lab - which makes it hard to access them. Both also need some (hardware) maintenance.

This hackweek I will focus on improving my drawing/painting skills.

The idea here is to study and understand how ephemeral storage for containers works and investigate if local storage could be avoided at all and Ceph used instead. Could new storage driver be developed to support Ceph storage:

• implement a POC deploying CaaSP v4 on top of AWS using: Spotinst's elastigroup

OSC is already available on Homebrew, but it is missing the integration with Staging as the openSUSE-release-tools are not available. In this Hackweek project I would like to get the openSUSE-release-tools running on macOS via Homebrew.

Using the camsource and vlc packages as an example. If camsource is configured to use a given dev/video[n] device with a choice of resolution in the width and height fields of a camsource conf file then if camsource is the first application to access the device captured images are as-expected. However, if an application like vlc is used for the same device (and exited) before starting camsource (e.g. to check the view from the camera before starting camsource) and if the camera supports higher resolutions than used in the camsource configuration what occurs is that camsource will not setup the camera to use the configured resolution and has a broken view of the camera output based on the vlc chosen resolution chopped to the camsource configuration. For example, with camsource configuration set to use 640x480 on a camera that supports 720x480 and vlc is used and exited before camsource is started then the captured camsource images contain two non-continuous partial image blocks with a horizontal border dividing them. I assume either vlc fails to fully reset the device configuration when exiting or camsource fails to initialize the device "from scratch" when starting. The two applications use different video device APIs but the setup and cleanup for the camera in each case is a very limited part of the application's functionality.

There's a long standing request to extend the output of dmidecode to something that would be machine-readable. Something like an XML or JSON-based format. Unfortunately this can't be implemented right now because the output of dmidecode is generated by open-coded printfs as the DMI table is being parsed, with no intermediate structures nor temporary buffers.

Termux is already bringing a terminal and debian package manager to Android.

Background

Given the number of different demands on our time and attention, it becomes increasing hard to focus and find the 'flow state' where a developer can be most productive. Interruptions due to chat notifications, email, and updater applets all break focus. Additionally, the desktop metaphor has in most cases failed to evolve as the browser and other MDI interfaces have become the focus for many users, and increased performance has allowed us to keep more tasks running and present on the desktop at once, presenting a higher cognitive load to the user.

I would like to learn more about something outside of engineering. I have selected to learn more about marketing; something our overall team is doing more of...

Since Kubernetes already has a clear path of "in-tree" volume plugin to CSI migration. I would like to understand the concept of CSI with writing a simple driver for Kubernetes.

Exactly what problem will this solve?

Simplify, modernize, and accelerate the process and tools for reviewing YES submissions from partners. Hopeful goals to accomplish:

Provisioning works with Autoyast/Cobbler for traditional clients, with profiles to enable major version upgrades. The goal is to offer that in a predictable way that can be scheduled and automated for salt minions.

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

Whether it's building a newer, upstream UBoot, EDK II, or merely a SLE based rootfs, I want to make this platform a realistic possibility for desktop, digital signage, labs, etc.

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

During the previous Hackweek [0], I have successfully implemented, tested and merged [1] an implementation of the entire C++ standard header . This time, my aim is to modernize the C++14-esque standard library [2] of HelenOS [3][4] with a C++17 feature - the header. The header is much larger than the header which I barely managed to implement and test in the allocated time for the previous Hackweek, but was mostly OS-independent as it relied only on previously implemented features of the standard library. The header, however, is limited by the filesystem API of the OS and as such implementing of the entirety of it might not be possible, limiting the scope of the project (which is a good thing due to the time constraints).

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.