This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]

openSUSE:GSOC ideas 2021

Jump to: navigation, search

Google Summer of Code 2021

The list of project ideas can be found on or on the github list that describes the topics in greater detail. Project's ideas are listed below. You can take over any of these roles and make openSUSE's GSoC participation a success. Here is what you can do:


Carrier is a project to build a small PaaS (Platform as a Service) on top of Kubernetes; it is an opinionated platform that runs on Kubernetes and takes you from App to URL in one step.

Expanding Integration Tests on Carrier

Description: Carrier integrates multiple components such as gitea, tekton, traefik, eirini, registry and quarks to enable PaaS features on top of Kubernetes.

Deliverable: The expectation is to take contribute to the project by writing documentation, writing unit, integration tests and developing features.

Mentor: Venkata Krishna Rohit Sakala - link

Skills: Kubernetes, GoLang, Bash.

Skill Level: Medium


IBus is an Intelligent Input Bus. It is a new input framework for Linux OS. It provides full featured and user friendly input method user interface. It also may help developers to develop input method easily.

Project Title: ibus pre-edit window support customized theme

Description: The original skin function of ibus in different desktop environments is based on GNOME-shell and GTK, we need to inherit and customize it, so that users can freely choose the style they need.

Deliverable: the modification to different desktop components to accomplish the target.

Mentor: @epico @hillwoodroc @qiangzhao - link

Skills: C, C++, Python3

Skill Level: Medium


Kanidm is an Identity Management system - it stores the information for people, accounts, systems and groups, to allow authentication and security decisions to be made for infrastructure. This can range from website single sign on, to wifi authentication, to ssh on linux servers.

Due to the nature of Identity Management the system must span a broad range of topics. From web userinterfaces and human interaction, social and cultural research to ensure we respect all identities we store, to security and hardening to prevent exploits, and high performance systems to support thousands of operations per second. There is a new challenge for everyone within the project!

Many Ideas with Kanidm

Description: Kanidm is an identity management project written in Rust. IDM services are a network store of users and groups for systems, websites and more, providing these with authentication and authorisation functionality. It aims to respect all peoples' identities and to store their data safely and correctly. IDM is a diverse area which values contributions from many people, from a variety of backgrounds.

Deliverable: As IDM spans many areas, we offer multiple possible focus areas. You should select one of these areas.

There is no requirement to complete all of these - we want you to attempt to work in an area of interest to you, and if you wish to change focus during the project, we can negotiate altering or changing which deliverable is your focus.

Possible deliverable areas (choose one):

  • Documentation and Accessibility - Improvements to project documentation, --help text, design of the user interface and command line tools, and extension of the CLI with new functionality.
  • HTTP Api Development - improve the usability, performance and features of the REST api attached to the server.
  • Database Performance - creation of a statistics collection and analysis process that can assist a query optimiser in improving query performance.
  • Rust FFI for RADIUS - rewrite the current RLM python module into Rust, with C-ffi bindings.
  • Your choice - there are many ideas in our issue tracker which you can choose from. Alternately, suggest your own!

Mentor: William Brown - link

Skills: Basic Programming. Nice to have - some knowledge of databases and Rust (but not required).

Skill Level: Beginner to Advanced. Each topic can be scaled up or down to your level, and areas of interest.


openQA is an automated test tool for operating systems and the engine at the heart of openSUSE’s automated testing initiative.

Project Title: Dynamic detection of error conditions from openQA test results

Description: openQA is an automated test tool for operating systems and the engine at the heart of openSUSE's automated testing initiative. It provides already several backends that allows testing an O.S. on a variety of architectures and scenarios including baremetal and different kinds of virtualized environment.

Reviewers of test results, especially failed tests, could benefit from a dynamic detection of error conditions that lead to test failures. The same or similar test failure in other jobs in the past or test jobs in the same build of a tested product could be cross-linked. Potentially new product issues could be found by applying "fuzzy search", "machine learning", "artificial intelligence". Existing, known problems should be marked automatically with the according bug references to not waste time on investigating known failures

If you haven't already, have a look at openQA in action.

Deliverable: Code is merged with the necessary tests to prove each feature created. Abstract interface design and at least one specific backend container implementation is expected (Docker) .

Mentor: @okurz, @cdywan - link

Skills: Perl, database, machine learning

Skill Level: Medium

Project Title: Container-based backend for openQA

Description: openQA is an automated test tool for operating systems and the engine at the heart of openSUSE's automated testing initiative. It provides already several backends that allows testing an O.S. on a variety of architectures and scenarios including baremetal and different kinds of virtualized environment.

A backend capable of directly interacting with different containers technologies would allow us to test container images before release - that could be really useful and enhance the development and publication workflow of containerized environments.

The new container backend ideally should provide an abstract interface to allow os-autoinst and the test cases to interact with the specific container technology ( that could be Docker, LXD/LXC, rkt, etc. ) and provide the same integration to our current workflow (e.g. tests that runs under a VM).

If you haven't already, have a look at openQA in action.

Deliverable: Code is merged with the necessary tests to prove each feature created. Abstract interface design and at least one specific backend container implementation is expected (Docker) .

Mentor: @okurz, @cdywan - link

Skills: Perl, Docker/rkt (General knowledge of containerized environment)

Skill Level: Medium


Phoeβe (/ˈfiːbi/) wants to add basic artificial intelligence capabilities to the Linux OS.

System-level tuning is a very complex activity, requiring the knowledge and expertise of several (all?) layers which compose the system itself, how they interact with each other and (quite often) it is required to also have an intimate knowledge of the implementation of the various layers.

Wouldn’t it be awesome if the machine could auto-tune itself and provide a self-healing capability to the user? Well, if that is enough to trigger your interest then this is what Phoeβe aims to provide.

Project Title: Phoebe - help increase data points density and data cleaning

Description: Phoeβe (/ˈfiːbi/) wants to add basic artificial intelligence capabilities to the Linux OS. Phoeβe uses system telemetry as the input to its brain and produces a big set of settings which get applied to the running system. The decision made by the brain is continuously reevaluated (considering the grace_period setting) to offer eventually the best possible setup.

Deliverable: Enhancements to the ML models, help increasing data points density and data cleaning

Mentor: Marco Varlese - Link

Skills: Must have: C, Python, Meson, Linux - Nice-to-have: artificial-intelligence, machine-learning

Skill Level: Medium


PRoot is a user-space implementation of chroot, mount –bind, and binfmt_misc.

Project Title: Implementing libseccomp in PRoot

Description: There is currently a major flaw with PRoot's seccomp implementation resulting in a segmentation fault on Linux kernels newer than the 4.8 version. Despite patches to address this, some of the core tests from the test suite are still failing on modern kernels. Instead of maintaining the legacy seccomp code, we would like to see libseccomp implemented. Below is a brief excerpt of the benefits this solution would provide:

We (libseccomp) will take care of cBPF creation, ABI issues, and any syscall changes when a new kernel is released. Maintaining a custom filter throughout all of that can be challenging.

This would also help with portability since libseccomp supports several different architectures.

Deliverable: The current test suite should pass on recent Linux kernels with no failures, on all of the arches that PRoot supports.

Mentor: @oxr463 - link

Skills: c, Linux, ptrace, syscalls, seccomp

Skill Level: Hard

Project Title: Porting PRoot to Rust

Description: There is already a proof of concept in progress, (See: However, this implementation is very basic and only runs on a single architecture. Work is still needed to complete a functioning prototype, as outlined here, proot-me/proot-rs#1:

Remaining steps for the bare minimum (single-tracee, no glue, no extensions, no ptrace-translation, no unix-socket translation, no qemu, -r/-R, -w and -b cli options only, no seccomp, and x86-64 with 64bits programs only)

Deliverable: Fully functional, albeit minimal, PRoot implementation written in Rust.

Mentor: @oxr463 - link

Skills: ptrace, rust

Skill Level: Medium

Project Title: PRoot / CARE and Intel SGX

Description: There are quite a few solutions that enable running docker images in an SGX enclave (Scone, Graphene-ng, Fortanix, etc.), but they are all either proprietary or hard to manipulate. It'd be nice to be able to use the combo PRoot/care to package a runtime for later re-execution within Intel SGX.

Deliverable: Proof of concept implementation for running containers in an enclave.

Mentor: @oxr463 - link

Skills: c, ptrace, sgx, encryption

Skill Level: Hard

Project Title: Unprivileged containers with PRoot

Description: OCI containers can be built and/or downloaded using img, and then run as any user via PRoot. There is already a proof of concept in progress (See: proot-me/proot#204). However, it is very rough, and there are several open bugs that still need to be patched before this can be merged upstream. We will also need some tests built out for the test suite to ensure there are no regressions.

Deliverable: A solution for running unprivileged OCI-compatible containers via PRoot.

Mentor: @oxr463 - link

Skills: c, go, Linux, containers

Skill Level: Medium


Rancher is a complete software stack for teams adopting containers. It addresses the operational and security challenges of managing multiple Kubernetes clusters, while providing DevOps teams with integrated tools for running containerized workloads.

Project Title: Logging Pipeline Plumber

Description: Rancher logging is powered by the Banzai Logging Operator. The operator is a powerful tool that empowers users to create complex filtering on their logs. Currently there is no good way to peel back filters and find where the breakdown is. Sometime users are targeting a particularly elusive log message making the feedback loop for their changes untenable. The goal of this project is to make a simple tool for users to reproduce a log message, determine what filter omitted the message


  • users are able to reproduce log messages from their own applications
  • users are able to replicate their log targets with minimal intervention the tool is able to identify which step in * the log pipeline is excluding the log message
  • (optional) the tool generates a visualization for how logs flow

Mentor: Jacob Payne - link

Skills: need: Kubernetes, helm, golang nice to have: Fluentd, Fluentbit

Skill Level: Medium


rpmlint is a command line tool for checking common errors in RPM packages. It can be used to check binary RPMs, source RPMs or plain specfiles before uploading or to check an entire distribution.

Project Title: Refactor old rpmlint checks

Description: The origins of rpmlint project go back to the year 1999. Even though lot's of things have been changed since that time, some rpmlint checks remained in the same shape for all that long 21 years. That means outmoded python constructs, spaghetti code, lack of comments, missings tests or just rpmlint checks that don't make any sense anymore.

The goal of this project is to review and refactor chosen rpmlint checks to use "functionalized" and modern approach. It's also needed to add basic tests before the refactoring so we are sure that there is no regression.

Deliverable: The result of this project will be multiple pull requests to the rpmlint repository with the refactored code and tests.

Mentor: @kstreitova - link

Skills: python, RPM, packaging, git, Linux

Skill Level: Medium

Project Title: Implement a proper testing framework

Description: Currently the majority of rpmlint tests are handled via running rpmlint for built RPM packages and comparing the results. This solution has disadvantages. It's hard to maintain it, adding of new RPM test packages requires lots of effort, it doesn't scale much further and last but not least RPM packages take space in rpmlint repository.

The goal of this project is to implement a proper testing framework that would use mocking for creating new testcases instead of requiring full binary RPMs as input. The second part is to transform existing RPMs test packages into the new framework.

Deliverable: The result of this project will be multiple pull requests to the rpmlint repository that implement the testing framework.

Mentor: @kstreitova - link

Skills: python, RPM, packaging, git, Linux

Skill Level: Medium/Hard


Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. Uyuni is a fork of Spacewalk that leverages Salt, React, Cobbler and containers to modernize it. Our documentation is written in AsciiDoc with the Antora toolchain and managed as code (in a git repository, with pull requests, reviews, etc). Uyuni is the upstream for SUSE Manager.

Project Title: Refactor client OS support in kits

Description: Adding a new client OS to Uyuni is not too difficult but it requires touching code in a ton of places (see, e. g. Most of the code for most of the clients is very repetitive.

This project is about refactoring that into a generic code path that simpy loads "OS enablement kits".

An OS-enablement kit would be comprised of e. g. one JSON file with the client OS name, client OS code, regular expressions needed to match /etc/os-release, the list of packages for the bootstrap repository, SQL to be inserted, etc.

Deliverable: Based on the above description and the existing code, implement an OSKit framework and convert the code from the existing clients (SLES, openSUSE, RHEL, CentOS, Oracle Linux, Ubuntu and Debian) to OSKits. Refinements will be needed along the way, you are not expected to get it right in the first try :-)

Mentor: @paususe and some other Uyuni core developer - link

Skills: A bit of Java, Python, SQL, JSON and XML will be required. Also, capacity to think in terms of generic solutions.

Skill Level: Medium

Project Title: Windows client support

Description: Uyuni supports many Linux clients (openSUSE, CentOS, SUSE Linux Enterprise, Red Hat Enterprise Linux, etc). Adding support for managing Windows clients sounds crazy but it may not be. This way, Uyuni Server would act as a Windows Server Update Service server.

Deliverable: Very similar to what supporting any other client means:

  • Build openSUSE's Salt packages for Amazon Linux 2. It may very well be the case that the RHEL packages just work but at least testing is needed. -
  • Onboard (register) Windows clients as Salt minions
  • Create bootstrap repository
  • Reposync support (i. e. make Uyuni Server able to download updates from Microsoft Updates so that they are available to Windows clients). Instead of adding support this to reposync, the most sensible way is probably to use my port of the Microsoft refrence implementation of the Server-Server and Server-Client protocols, and modify them to store the data in the Uyuni Server Postgresql database.
  • Generate and process Windows Update patches and security information (everything comes from Microsoft and is already downloaded and preprocessed by the Server-Server sync library, it's just a matter of putting it in the database)
  • Identify other Uyuni features that may need specific Windows codepaths/contents, e. g. PXE booting
  • NOT expected: building Windows images, using Windows as a build host, running Uyuni Server on top of Windows, manage Windows Embedded, etc.

Mentor: @paususe + Uyuni developers TBD from the SUSE Manager team - link

Skills: You will need to have a good understanding of Linux and Windows, and be comfortable with version control using git and GitHub. PostgreSQL and .NET, and some JSON, Python and Java knowledge will be needed (you will be mostly looking at existing code and adding new sub-cases to it).

Skill Level: Difficult

Project Title: Enhance Debian and Ubuntu support

Description: Uyuni currently supports Ubuntu officially as a Salt client. Debian is not officially supported. This project is about implementing what's missing.

Deliverable: As many as possible of this list

  • Generate and process Debian patches and security information (CVE information from the Debian Security Advisories - )
  • Generate and process Ubuntu patches and security information (CVE information from the Ubuntu Security Noticies -
  • Display in the UI the right information about packages to be updated (what's missing is mostly the backend part, not the UI). Involves implementing a apt notify beacon (uyuni-project/uyuni#1938)
  • Autoinstallation of Debian and/or Ubuntu. This requires implementing preseed, kickseed and/or cloud-init awareness in Uyuni (which should not be too difficult since Uyuni already supports autoinstallation with AutoYaST, KickStart and Yomi)
  • Add Debian/Ubuntu-specific filters, or enhance the existing ones, with Debian/Ubuntu specifics.
  • Build Debian/Ubuntu OS images (mostly a matter of providing a Kiwi template) and/or containers

Mentor: @paususe + another Uyuni developer TBD from SUSE - link

Skills: You will need to have a good understanding of Linux, and be comfortable with version control using git and GitHub. You will need some PostgreSQL, JSON, Python and Java skills. Familiarity with Debian and package management.

Skill Level: Medium

Project Title: Add as a client

Description: Add a new client OS to Uyuni. It can be a new Linux OS (e. g. Alma Linux, Rocky Linux, Manjaro, RasperryOS), FreeBSD, macOS, AIX, Solaris... you name it.

Deliverable: New client is supported with the essential functionality (content management, configuration management, managed as a Salt client via either salt-ssh or salt-minion)

Mentor: @paususe + some other core Uyuni developer - link

Skills: Knowledge of your new client OS, some Java, some Python, some SQL.

Skill Level: Depends on the new OS to be added, e. g. RaspberryOS will be easy; macOS will be more difficult.

Project Title: Convert Virtual Systems page to ReactJS

Description: The Uyuni web interface is mostly implemented based on aging technologies like JSP while the new pages are written in ReactJS. The goal of this project is to add the missing ReactJS components, like a tree table and reimplement the Systems > System List > Virtual Systems page in ReactJS. Of course the page will need some fresh paint to be prettier and be more useful.

This task is also likely to touch the database queries to optimize them when displaying the page for big number of virtual hosts and machines.

Deliverable: The result of this project will consist in one or more pull requests to the Uyuni repository implementing a working ReactJS version of the page.

The newly created reusable ReactJS components will need to be provided with a story and documentation to explain how to use them.

Mentor: @cbosdo - link

Skills: ReactJS and Java. Hibernate and SQL are a plus.

Skill Level: Medium

Project Title: Translate Uyuni to language X

Description: Uyuni is available only in English. This project is about translating it into some other language, e. g. Simplified Chinese, Russian, German, French, etc. There are some unmaintained (years) old translations that can be reviewed but they cannot be blindly taken, many text strings have changed.

Deliverable: Translation of: UI, Command-line tools, YaST module, Main documentation guides: installation guide, upgrade guide, client configuration guide

Mentor: @paususe - link

Skills: Target language knowledge and POT translation (e. g. with WebLate, Lokalize, or any other tool to manage gettext files). A Linux VM with at least 8 GB of RAM is recommended to run Uyuni and see the UI.

Skill Level: Easy

Project Title: Package Uyuni for Debian

Description: Currently, Uyuni is only available and runs on openSUSE Leap. A port to CentOS is in the works. In order to make it more popular, let's package it for Debian (which should also run easily on Ubuntu). It's your choice to decide whether you want to use debbuild (i. e. build .deb packages from the same .spec files we use for openSUSE, that requires some black magic with OBS and it will not be accepted by Debian upstream) or create native Debian packaging.

Deliverable: A packaged, mostly-working Uyuni Server and Proxy and its dependencies. It is not required to package or make it run 100% of the features during this GSoC project but at least the core functionality should work.

Required working features at the end of this project (definition of done):

Content management: package sync, Content Lifecycle Management, etc (should work mostly out of the box, it's just a matter of packaging). Configuration management, OpenSCAP scan, Managing Salt clients

Nice to have features: Building OS images (no big problems expected), Building containers (no big problems expected), CVE scan (requires #127), Managing traditional clients (it's mostly packaging but a lot of it)

Mentor: @paususe (inactive Debian Developer) and some other Debian Developer(s) currently (either currently employed by SUSE or interested in Uyuni, it'll be easy to find them) - link

Skills: Linux and packaging. Open Build Service knowledge a plus (but you can learn it on the way :-))

Skill Level: Easy to medium if you already know packaging. Please note Uyuni comprises a ton of packages and dependencies, so while this project is no superdifficult per se, it requires that you already know packaging and you a disciplined.

Project Title: Add KDE support

Description: Uyuni is mostly used to manage Linux servers but why not use it to manage Linux desktops?

KDE provides a number of files that can be tuned and tweaked to configure kiosk mode, background, where the task manager is, what Plasma add-ons are installed, etc.

Deliverable: This project is about creating Salt formulas, forms, grains, modules, pillars, etc for a sysadmin to be able to configure KDE desktops, much like a Windows sysadmin would do with Group Policy Objects.

With that, Uyuni should be able to:

  • Configure basic desktop parameters such as background color/image, locale, where the task manager is, how many desktops, etc (full list to be determined after examining the KDE docs; information is a bit scattered and may be out of date)
  • Install/remove Plasma add-ons and configure them
  • Configure kiosk mode parameters full list to be determined after examining the KDE docs; information is a bit scattered and may be out of date) -

Mentor: This project will be co-mentored by the KDE and Uyuni communities, as expertise from both sides will be needed. @davidedmundson (KDE) @paususe, @joesusecom, @benediktwerner - link

Skills: You will need to have a good understanding of Linux, and be comfortable with version control using git and GitHub. Python and YAML. Salt (or alike: Chef, Ansible, etc) knowledge will be a plus. Being able to read C++, Qt and KDE code will help in case the documentation is out of date and reading code is the only way to find some configuration parameter.

Skill Level: Medium. Technical complexity should no be that high (formulas with forms are easy to write) but locating the appropriate KDE parameters may require some digging and lots of test and error.


Project Title: Improve adding security options in Yast security modul

Description: When trying to add support for an option to the Yast security module (see yast/yast-security#93) it turned out that 26 adjustments would be needed in various places. Since security settings of a system have increasing importance, adding options should be as simple as possible and require changes only in a few places, e.g. in a central configuration file.

Deliverable: A working pull request merged into

Mentor:rhabacker - link

Skills: Linux, Ruby and shell scripting knowledge

Skill Level: Medium