Once again, the SUSE band is coming together to make music and we're planning a party this time round!!! We have a band name :-)

Create an OpenVPN gateway based on SLES 12 JeOS Starting next month, I'll be working remotely from my home office. In order to simplify my setup, I'd like to have a gateway that connects my machines to the Nuremberg and Prague offices through OpenVPN.

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: 1. Actions are currently scheduled in the minions using the schedule module of Salt. This brings problems with reliability as for instance a minion can be down at the specified schedule time which leads to actions not being executed. Scalability can be an issue as actions being scheduled for many minions might return results to the server at the same time. Instead it might be better to keep control over scheduled actions on the server to allow batching of actions as well as downtimes of minions or even the server. There is a work in progress branch to get started.

1% of SUSE Manager's functionality in 0.1% of the lines of code

Let's create a much simpler SUSE Manager — one you could use at home! Users should be able to deploy and operate in minutes with minimal configuration, while still retaining the very core features that make SUSE Manager useful!

terraform-provider-libvirt supports CoreOS ignition file/content, which end rendered as kernel command line options (the provider does some nice stuff like allowing you to pass the json content and it will take care of putting it into a temporary file). The idea is to:

The idea is to explore the technologies and the various components to realize some AI to predict pitfalls in source code which can potentially generate run-time misbehaviours. The potential area where this idea could have positive implications are:

Let's make reposync faster

Every day,

Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour. The project is to dig into avahi source code to modernize it if possible and fix bugs.

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. There are several frameworks that could be helping in that direction. The goal here is to create a Proof of Concept with the virtualization features moved into an add-on.

We already tried to improve the Jangouts data model in the past and, although we made quite some progress, we did not finish it. I've been playing a bit with React and Redux lately, and I would like now to try a different approach replacing Angular with that combo. Using Vue.js might be another option too. Of course, we are not going to rewrite Jangouts in just one week, but let's see how far we can go. By the way, the redesign branch contains some interesting stuff from one of the GSoC that we should consider.

Simplify the codebase by using a more modern toolkit to accelerate maintenance and future development. Enjoy Hakkaweek!

Uyuni is an heterogeneous and giant project (actually it is a beast) made of many pieces, many languages, many internal architecture structures, and also very old and new technologies live in it. Said that, and based on the fact Uyuni delivers tons of features/functionalities not all the end users use, it is not trivial at all to understand

Deploy Uyuni as an app from the Rancher marketplace - or install via Helm on any Kubernetes cluster, on any OS, or any Public Cloud.

The dream

Bug reports can be a great source of information, but usually finding the information requires extensive work in reading through all of the discussions and understanding the details about it. Could it be that machine learning can be used to extract meaningful information out of that? That's what this project is about.

Following up on the experiment from last Hackweek ( https://confluence.suse.com/display/~digitaltomm/Business+Intelligence+in+SCC ), it would be great having a production instance of Metabase running in the SCC EKS cluster, connected to the production database of SCC.

Project Description

• Create an automated L0-support-like analytics solution for supportconfig data that is tiered across a customer's environment and SUSE environment (similar to a very modular AIOps Edge-Core approach). A pictorial overview of the ecosystem

Project Description

Terraform's remote backend requires a Terraform Cloud account and has an initial limited offering. While the initial offering is suitable for small resource management and teams this quickly becomes an issue as usage demands increase. In addition Terraform's remote operations (plan,apply, etc) are executed on HashiCorp's cloud resources which present issues for sensitive data such as passwords and access keys. Users are also constrained to as what tooling is available on the remote execution environment for example having kubectl as part of a local-resource. This project aims to address these shortcomings in a native Kubernetes implementation.

Building on the lessons learned in the previous HackWeek, attack the Server specifically to create a set of containers deployable on k3s via Helm.

Project Description

This project aims to build a unikernel that has a sole purpose: run WebAssembly applications.

Introduction

When issues are found in software (being them security or not), it is not always trivial to find and keep track of all products and versions that could potentially be affected by them.

Project Description

BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).