Create a set of ready to use Dockerfiles based on OpenSUSE, and find a nice home for them to live in. Useful containers or just for fun, let's dockerize-it all.

The docker way of updating containers is to build a new image with the updated binaries and files, which creates a security concern. The docker way is not anymore running "zypper update" in the containment but to update the whole image in the image registry (hub docker if we are talking about public registry) and then pull the image update from there, stop the outdated containments and replace them by starting new containments based on the new image.

Discourse is a really great opensource forum, written in Ruby on Rails and Ember.js. We should try to use it to complement mailing lists and IRC in internal communication, when we need persistent, searchable discussions (with helpful links to the outside world) for a broad and offtopicky subjects.

Micro-service for - making a report

Minimal objective

This is what we consider is the minimum result we can achieve at the end of the hackweek.

During the last CSM workshop I started to refactor zypper-docker in a way that: - The CLI code and the "library" part got split.

As I'm already a maintainer of the plugins for Drone CI and we are nearby of a new releases which totally changed the structure of the plugins I would like to start migrating the existing plugins to the new structure. A list of pending plugins can be found here. For communication it makes sense to join the Gitter chat.

I would like to continue to work on a web UI for the Docker registry. I know we already got Portus which is based on Ruby on Rails, but I would prefer a project based on Golang with a singlepage application for the frontend based on RactJS. So because of the singlepage application we are forced to write proper APIs that gets consumed by the javascript application, beside that I also want to add a CLI client for managing the system. You can find the project at https://github.com/harborapp.

Clair is a static vulnerability analyzer for containers. Currently it supports containers based on Debian, Ubuntu and RedHat. I already started this project on the CSM workshop, now I want to finish the integration for openSUSE and SLES based container images. You can track the changes at https://github.com/coreos/clair/pull/199.

The aim of this project is to finish up the work already done in previous editions of Hackweek in regards to zypper-docker. That being: - Separation of the CLI part and the library.

OpenFaaS - Functions as a Service Get familiar with one of the hottest topics for this year: https://www.openfaas.com/

How to deploy container - Docker based on SUSE CaaS Platform.

Build a base image and template (both kiwi and Dockerfile) for openSUSE Leap 42.3 using the native OBS container building feature. Results/WIP will be available here:

Let's containerize SUSE Manager! This will open up different (and interesting) scenarios: - From a development perspective: learn about all the components that constitute SUSE Manager

kubeojo in 10 seconds-click-me to visualize-demo-link

code:

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.