Starting from prometheus ( and grafana if needed), learn how to monitor kubernetes and docker and do some valid alert/graph etc. https://docs.docker.com/config/thirdparty/prometheus/

Description

Experiment with and implement a server (openSUSE Kubic, SUSE CaaSP) with connected thin clients (Raspberry Pi) that executes GUI applications from docker containers running on the server.

Mental poker is a principle and also specific protocol to play card games without a single trusted party. This includes shuffling cards, enforcing card visibility and commitment schemes. Imagine playing rock-paper-scissors via phone only. libTMCG is an implementation of the protocol and SecureSkat is an application of this protocol/library to the popular German card game Skat.

The usual baby-phones and phone based surveillance solutions do not fit my needs: - We live in townhouse with reinforced concrete walls (the signal from the babyphone is not strong enough)

2018

new hack

motivation

Lots of crucial steps in the SUSE/openSUSE product build workflow are not known or not even accessible by many people but hidden as "custom scripts" on "some machine" in the worst cases. Nowadays infrastructure and build pipelines should be written as code, e.g. in git repos, with UI frontends to show the always current state of what is going on, what needs to be done to release products, where are problems. The least we can do is learn a bit more in this direction.

Currently helpers for maintenance of SLE/openSUSE such as osc omg exist just as git repo, lets have them as packages.

The openSUSE.org official infrastructure is getting bigger and complicateder, so #microservices and #serverless FTW! :smiley: :thumbsup: :icecream:

Glowing Nixie Clock * A Nixie tube (English: /ˈnɪk.siː/ NIK-see), or cold cathode display, is an electronic device for displaying numerals or other information using glow discharge.

All our packages have a *.changes file and ideally that file would mention relevant changes from upstream, i.e. during version updates. Currently, we find that information manually when packaging Haskell software. This is unsatisfactory because of the sheer size of the package set and the massive number of updates we receive from Hackage. The packaging itself is completely automatic, but editing the *.changes files is not and this issue prevents us from shipping more packages in Tumbleweed and elsewhere. Now, during this Hackweek I'd like to write code that given two Haskell package versions old and new can determine the upstream changelog entries between those two and create a pleasantly formatted entry for the *.changes file that won't need any manual editing to pass the review team. Then I'd like to integrate this into cabal2obs, or maybe even cabal2spec.

In day to day job I often wait for openQA job to change a state. I plan to create chrome plugin which would allow to watch for some certain job and will send you notification when run is end.

I need to get a basic understanding about MD software RAID setup only via command line tools to be able to understand,

Explore the possibility to have a self sufficient frontend server running locally. This server would compile all the frontend code and act as a proxy/middleware pointing either for a dev ref-server or to a local SUMA instance. This way would be possible to do modifications in frontend even without having a SUMA server running locally. http://imagebin.suse.de/2542/img

Some ideas from the list: Small ones:

What is it about? I write lots of notes, about almost everything. Writing is a very important part of my work and of my organization in general.

git-deps and hatop deserve some more native packaging love. let's improve this and make a good package for multiple distros when possible.

SSO for kanku

As we use kanku for testing/debugging our OBS Appliance images.

I want to connect to matrix.org via weechat in Leap 15.0. 1. I need the matrix script

I want to improve myself in Perl & Mojolicious and I want to have a nice open-source self-hosted message board / forum written in Perl. Let's combined it into one ultimate goal. I would like to have:

Background

Candidates

For testing some of the upstream Linux drivers we maintain it is necessary to emulate the hardware as we're getting bug reports for the upstream drivers but have no chance to test fixes. Once the upstream drivers can be emulated we could focus on emulating hardware where only downstream drivers do exist and then write new drivers to be upstreamed.

Every time we went to UEFI Plugfest, one of the frequently asked questions is how to setup a PXE/HTTPBoot server. Besides, we also have to setup and test the server before the event. Although we already have the document(*), it may be easier to deploy with a container image. My goal is to learn how to package a container image in SLE/openSUSE and create a flexible image for the fast deployment of PXE/HTTPBoot server.

I want to dive deeper into React using its Material-UI components to prototype a web interface for SUSE's new Repository Mirroring Tool (RMT). Updates:

Leap 15 and TW supports Transactional Server system role but some additional work is needed to have a transactional desktop system role. The purpose of this hackweek is to document what need to be fixed and try to fix it.

We provide tftp server and RPMs containing the installer to run from tftp. Disadvantage is, that the user needs to setup a tftp boot system first. Why not putting everything in a container, so that the admin only need to run the container and can then choose on the to be installed machine, what he wants install? And following this, put the container in a kubernetes cluster like SUSE CaaS Platform.