The salt-toaster (https://github.com/openSUSE/salt-toaster) is a tool created and developed by SUSE employees that we've been using for testing Salt since few years ago. This tool uses pytest in combination with Docker containers to allow testing the multiple versions of the Salt codebase and as well as Salt packages across multiple distributions.

Mash is a Python based CI/CD pipeline for automated testing and publishing of public cloud images. Currently the production and development deployment for the package is inconsistent, slow and manual. This is a barrier to rapid development, deployment and testing. It also means the development workflow is different than production. This can lead to production issues which were not seen during development. In order to modernize the Mash workflow I plan to spend the week digging into a plethora of tools to first learn then build out a new workflow. The goal is to simplify deployment by choosing tools that provide consistency, modularity and repeatability. By leveraging the best tools available we can harden the code and accelerate the release cycle.

There are various home assistant solutions out there but all of them transfer your voice to some server for processing. This is a no-go for sane people although the technology is interesting and could be useful. There are various open source tools out there to achieve the same result but there is no turn key open source self hosted solution. The goal of this project is to implement a way to have a home assistant running locally - ideally with one command. The project that is closer to the desired result is Mycroft (https://mycroft.ai/). It is very easy to run the client side components using one docker command but their backend is running remotely. All the tools they use though are open source so it only needs one to do the work and package them in a nice little docker-compose file (https://mycroft-ai.gitbook.io/docs/about-mycroft-ai/faq#can-mycroft-run-completely-offline-can-i-self-host-everything).

Zero-ish downtime deploy on da cheap!

This project aims to get a 0-ish downtime deployments (very easily achievable with Kubernetes) just using:

Project Description

For quite some time I am providing a ResourceSpace container on Docker Hub. It is meanwhile pulled about 234K times but unfortunately still based on Ubuntu. Meanwhile I have updated the base to Ubuntu 20.04, but I would like to move it to openSUSE instead. With ResourceSpace 9.5 coming out soon I see a possibility of introducing this switch. Enno Gotthold also did a great job of packaging ResourceSpace on OBS, so this could be used as a starting point for the container.

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

In this project I would like to extend the capabilities of the SLE Release Management Container. This container is used by some colleagues in the SLE Release Management team to have access to osc and other Release Management critical commands inside a container environment. This includes the beta-emails project to send our beta announcements.

Project Description

regview is a heavily modified fork of the (no longer maintained) reg tool by Jess Frazelle for listing images in a Docker registry. Some features of reg were removed (like the webserver, to make it only cli) and others added. Some bugs were fixed (and PR's submitted) and others added as well.

Project Description

Create a set of container images for serving a mock git server and mock git clients in a Kubernetes cluster that can be used as building blocks for an interactive git playground.

Project Description

I recently used melange and apko to build a from scratch image. The result was a set of auditable and easy to use container and apk repository. The toolkit reduces the work need to make from scratch images with minimal work on the actual docker container(which can be quite painful if you've tried making a from scratch image on your own).