Technical talks at universities by agamez

Description

This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.

For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.

Goals

• Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
• Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
• Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.

Resources

• Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
• SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.

---

Multi-pod, autoscalable Elixir application in Kubernetes using K8s resources by socon

Description

Elixir / Erlang use their own solutions to create clusters that work together. Kubernetes provide its own orchestration. Due to the nature of the BEAM, it looks a very promising technology for applications that run in Kubernetes and requite to be always on, specifically if they are created as web pages using Phoenix.

Goals

• Investigate and provide solutions that work in Phoenix LiveView using Kubernetes resources, so a multi-pod application can be used
• Provide an end to end example that creates and deploy a container from source code.

Resources

https://github.com/dwyl/phoenix-liveview-counter-tutorial https://github.com/propedeutica/elixir-k8s-counter

---

Setup Kanidm as OIDC provider on Kubernetes by jkuzilek

Description

I am planning to upgrade my homelab Kubernetes cluster to the next level and need an OIDC provider for my services, including K8s itself.

Goals

• Successfully configure and deploy Kanidm on homelab cluster
• Integrate with K8s auth
• Integrate with other services (Envoy Gateway, Container Registry, future deployment of Forgejo?)

Resources

• https://kanidm.github.io/kanidm/stable/

---

Integrate Backstage with Rancher Manager by nwmacd

Description

Backstage (backstage.io) is an open-source, CNCF project that allows you to create your own developer portal. There are many plugins for Backstage.

This could be a great compliment to Rancher Manager.

Goals

Learn and experiment with Backstage and look at how this could be integrated with Rancher Manager. Goal is to have some kind of integration completed in this Hack week.

Progress

Screen shot of home page at the end of Hackweek:

Day One

• Got Backstage running locally, understanding configuration with HTTPs.
• Got Backstage embedded in an IFRAME inside of Rancher
• Added content into the software catalog (see: https://backstage.io/docs/features/techdocs/getting-started/)
• Understood more about the entity model

Day Two

• Connected Backstage to the Rancher local cluster and configured the Kubernetes plugin.
• Created Rancher theme to make the light theme more consistent with Rancher

Days Three and Day Four

• Created two backend plugins for Backstage:

  1. Catalog Entity Provider - this imports users from Rancher into Backstage
  2. Auth Provider - uses the proxied sign-in pattern to check the Rancher session cookie, to user that to authenticate the user with Rancher and then log them into Backstage by connecting this to the imported User entity from the catalog entity provider plugin.

• With this in place, you can single-sign-on between Rancher and Backstage when it is deployed within Rancher. Note this is only when running locally for development at present

Day Five

• Start to build out a production deployment for all of the above
• Made some progress, but hit issues with the authentication and proxying when running proxied within Rancher, which needs further investigation

---

Rancher/k8s Trouble-Maker by tonyhansen

Project Description

When studying for my RHCSA, I found trouble-maker, which is a program that breaks a Linux OS and requires you to fix it. I want to create something similar for Rancher/k8s that can allow for troubleshooting an unknown environment.

Goal for this Hackweek

Create a basic framework for creating Rancher/k8s cluster lab environments as needed for the Break/Fix Create at least 5 modules that can be applied to the cluster and require troubleshooting

Resources

https://github.com/rancher/terraform-provider-rancher2 https://github.com/rancher/tf-rancher-up

---

Kanidm: A safe and modern IDM system by firstyear

Kanidm is an IDM system written in Rust for modern systems authentication. The github repo has a detailed "getting started" on the readme.

Kanidm Github

In addition Kanidm has spawn a number of adjacent projects in the Rust ecosystem such as LDAP, Kerberos, Webauthn, and cryptography libraries.

In this hack week, we'll be working on Quokca, a certificate authority that supports PKCS11/TPM storage of keys, issuance of PIV certificates, and ACME without the feature gatekeeping implemented by other CA's like smallstep.

For anyone who wants to participate in Kanidm, we have documentation and developer guides which can help.

I'm happy to help and share more, so please get in touch!

---

Agama installer on-line demo by lslezak

Description

The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.

The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.

The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.

As a proof of concept I already created this on-line demo.

The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).

Goals

• Create an Agama on-line demo which can be easily tested by users
• The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
• Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)

TODO

• Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
• Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
• Fix changing the product, currently it gets stuck after clicking the "Select" button.
• Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
• Allow changing the UI language
• Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
• Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.

Changing the UI language

This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.

Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.

Resources

• Agama sources
• Experimental proof of concept demo
• The respective source code change

---

Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino

Description

A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.

The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.

On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).

I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.

Goals

• Learn about Rust and micro-controllers (ESP32-C3)
• Learn about mobile applications (Android and Kotlin)

Resources

• Shamir's Secret Sharing
• The esp-rs Book
• Android - Kotlin

---

Hack on isotest-ng - a rust port of isotovideo (os-autoinst aka testrunner of openQA) by szarate

Description

Some time ago, I managed to convince ByteOtter to hack something that resembles isotovideo but in Rust, not because I believe that Perl is dead, but more because there are certain limitations in the perl code (how it was written), and its always hard to add new functionalities when they are about implementing a new backend, or fixing bugs (Along with people complaining that Perl is dead, and that they don't like it)

In reality, I wanted to see if this could be done, and ByteOtter proved that it could be, while doing an amazing job at hacking a vnc console, and helping me understand better what RuPerl needs to work.

I plan to keep working on this for the next few years, and while I don't aim for feature completion or replacing isotovideo tih isotest-ng (name in progress), I do plan to be able to use it on a daily basis, using specialized tooling with interfaces, instead of reimplementing everything in the backend

Todo

• Add make targets for testability, e.g "spawn qemu and type"
• Add image search matching algorithm
• Add a Null test distribution provider
• Add a Perl Test Distribution Provider
• Fix unittests https://github.com/os-autoinst/isotest-ng/issues/5
• Research OpenTofu how to add new hypervisors/baremetal to OpenTofu
• Add an interface to openQA cli

Goals

• Implement at least one of the above, prepare proposals for GSoC
• Boot a system via it's BMC

Resources

See https://github.com/os-autoinst/isotest-ng

---

Hacking on sched_ext by flonnegren

Description

Sched_ext upstream has some interesting issues open for grabs:

• core event counters
• topology: Use cpumasks

Goals

Send patches to sched_ext upstream

Also set up perfetto to trace some of the example schedulers.

Resources

https://github.com/sched-ext/scx

---