Table of Contents

Administrators and Mentors

We will list the potential mentors in this place. For now, if you have any questions, please contact the GSoC administrators:

George Zaronikas (gzaronikas) and Ali Ok (@aliok_tr) .

Communication channels

Gitter    : JBossOutreach/GSoC - Gitter 

Please take note - These channels are about generic doubts. For project-specific doubts you will need to contact project mentors and channels specified in the project description.

Notes for contributors

We prefer the contributors who have made more than one non trivial contributions with the corresponding project team they wish to work in GSoC tenure and specify that in the proposal.

Points to consider while choosing any project

1. You meet at least 50 percent of the requirements. The remaining skills can be honed on the go, so don't worry if you lack some.

2. You can relate to the project idea and you have used something related to the project as a user.

3. You are willing more toward learning the skills and less toward boasting about the skills you have already.

Suggested steps after choosing a favorite project

1. Start to use product/tool/API as a user or hello world client application.

2. Setup the development environment for the project and start to use your own build.

3. Look for newcomer bugs and try to get your head around them.

4. Let us know if you feel stuck at any stage.

Proposal document

Keep in mind to keep the documentation length of around 6 pages

- Page 1 : Abstract of one page about project according to your understanding.

- Page 2-4 : Plans of 3-5 days chunk. Including buffer.

- Page 5 : Previous OpenSource pull requests within or outside of project you wish to work on.

- Page 6 : Personal details including Name, Connection details, Professional profiles, availability during GSoC period etc.

You may find a sample GSoC proposal document here which was for this idea.

Idea template (for mentors)

Project title

Summary of idea:

-Idea

-Feature A

-Feature B

Knowledge prerequisite: Languages/Technologies goes here

Github repo:

Project size: medium (~175 hours) or large (~350 hours)

Skill level: Beginner/Intermediate/Advanced

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Associated JBoss community project(s):

Idea Proposals

Drogue IoT – CoAP TLS support

Summary of idea:

During last year's Google Summer of Code project, we got a CoAP protocol adapter contributed to the cloud side of the project. However, transport encryption was out-of-scope for the project back then, as that would be been too much for the summer. Building on last year's contribution, this year the protocol adapter could be extended to support CoAP transport encryption using DTLS.

• Learn how CoAP and DTLS are supposed to work
• Find a suitable DTLS implementation
• Extend the existing CoAP protocol adapter in the cloud with support for DTLS

We understand that the combination of Rust, DTLS, and CoAP isn't a mainstream topic. So it is ok for us to learn some of the technologies, during GSoC. However, you should have some basic understanding of what is required, and have a plan upfront. This is not a beginner project.

Knowledge prerequisite: CoAP, Rust, TLS, Kubernetes (not all, but some)

Github repo: https://github.com/drogue-iot/drogue-cloud/tree/main/coap-endpoint

Skill level: Intermediate

Project size: large (~350 hours)

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Device certificate management for the web console

Summary of idea:

Drogue Cloud supports authenticating IoT devices using X.509 client certificates. During last year's GSoC, some management tasks for the drg  command line tool had been added to make this more user friendly. However, the current web console does not have support for that yet.

The goals for this project are:

• Create some UX flows for the console
  • Allow viewing the current configuration
  • Allow creating new/editing existing configuration
  • Both on the device (certificates) as well as the application level (trust anchors)
• Implement the user interface
  • This will mostly be frontend code (but note, it is using Rust and WebAssembly!)
  • Any necessary changes in the backend
• Create some tests, which also test this in combination with the drg  tool

Note: This is not your regular NodeJS/React project. The web console is written in Rust using WebAssembly. It still uses the PatternFly toolkit tough.

Knowledge prerequisite: UX, Rust

Github repo: https://github.com/drogue-iot/drogue-cloud/tree/main/coap-endpoint

Skill level: Intermediate

Project size: large (~350 hours)

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jean-Baptiste Trystram <jbtrystram@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Display application metrics in the console

Summary of idea:

Drogue Cloud records application metrics for the IoT stack. Things like number of devices registered, messages per second, etc. These metrics are tagged with an application (tenant) tag, so that it is possible to extract metrics on a per-tenant basis. It would be nice if those could be shown in the console, so that a tenant/user can see the current usage of this tenant specific service.

The goals for this project are:

• Create some UX flows for the console
  • Come up with a list of metrics to show
  • At least show devices registered, messages per second, bytes per second
• Implement the user interface
  • Enhance the backend to provide the required information for the frontend
  • Create placeholders for information that is not there yet: for example, in order to show the current maximum number of devices, we do need the maximum number. However, this isn't currently implemented, as this will be implemented as part of "quotas". So there should be a place in the backend, where it is currently possible to provide/configure these max values manually.
  • Implement the visualization in the frontend
  • Use the PatternFly toolkit
  • Find a charting toolkit which can be used in this environment
• Create some tests

Note: This is not your regular NodeJS/React project. The web console is written in Rust using WebAssembly. It still uses the PatternFly toolkit tough.

Knowledge prerequisite: UX, Rust

Github repo: https://github.com/drogue-iot/drogue-cloud/tree/main/coap-endpoint

Project size: medium (~175 hours)

Skill level: Beginner

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jean-Baptiste Trystram <jbtrystram@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Knative event source

Summary of idea:

Knative is a serverless framework for Kubernetes. Drogue IoT Cloud is providing IoT friendly APIs on the cloud side. As Drogue Cloud uses CloudEvents, both technologies can work together quite nicely.

However, in order to consume events from Drogue Cloud using Knative, one needs to use the Kafka Event Source. We would like to be able to offer a dedicated "Drogue IoT event source", which connects using OAuth2 or API tokens, and get only configured using the Drogue Cloud specific connection parameters. Also, sending back commands using a Drogue Cloud Sink should be possible. This can use the MQTT integration API of Drogue Cloud, in order to consume messages. And the command endpoint, to submit commands back to devices.

The goals of the project are:

• Create a Drogue Cloud sink and source
  • Backed by the MQTT integration API and the HTTP command API
  • Authenticating using OAuth2 and API tokens
• Documentation
• Example deployment using Helm
• Tests

Knowledge per-requisite: Go

Project size: large (~350 hours)

Skill level: Intermediate

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Dejan Bosanac <dbosanac@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Quotas

Summary of idea:

Drogue IoT Cloud allows users to create device and send messages. However, that should be limited, according to a set of rules an administrator can configure. This should limit things like: Number of devices created, number of messages sent per second, number of bytes sent per second.

The goal of this project is:

• To come up with an RFC (mini specification) defining what quotas should exists and how they could be enforced
  • This should leave room for future extensions
  • Not all specified quotas need to be implemented during GSoC
• Implement
  • The configuration model
  • Enforcing of at least
    • Number of devices that can be created
    • One rate limiting quota: like number of messages sent in the last 4 hours
• Adapting existent Helm deployment scripts
• Document
• System tests ensuring the enforcement work

Outside of the scope is:

• Implementing new metrics: We already record some metrics. If more are needed, we need to decide this during the RFC phase, and we will implement that for you.

Knowledge pre-requisite: Rust, Prometheus

Github repo: https://github.com/drogue-iot/drogue-cloud/tree/main/console-frontend 

Project size: large (~350 hours)

Skill level: Intermediate

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Web Flasher

Summary of idea:

Part of Drogue IoT is a firmware for microcontrollers, written in Rust. The other part is a cloud side solution. Bring that in combination with a Web IDE, you might soon find yourself in a position that you want to flash a microcontroller over USB from your web browser. As a browser API for accessing USB devices attached to the user's machine exists, this should be possible in general.

The goal of this project is to bring together a hand full of projects and technologies, and create an frontend application, for the browser, to flash embedded devices. This needs to be done using Rust, and WebAssembly, so that existing code from https://probe.rs/, which can talk to devices, can be re-used.

• Make it possible to use probe-rs on a WebAssembly target
  • Allow using an additional USB implementation (vs the current libusb based one)
  • Implement an additional one using WebUSB APIs
• Create a frontend (single page) web application using Rust and WebAssembly
  
  • Allowing to select a firmware from the local machine
  • Flashing this to the device
  • Allow selecting a firmware from a remote endpoint (HTTP GET) too

Knowledge pre-requisite: Rust, WebAssembly

Project size: large (~350 hours)

Skill level: Advanced

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

EAT  - Testing Infinite Software Project Versions

Summary of idea:

The innovative part of EAT is creating the test once and testing with any version of the tested software. It may be firstly applied for the JBoss Servers, but, in general, a similar structure, can be used for creating tests about any software with multiple versions or for multiple software programs that have a part of the testsuite in common. EAT is a project under the ΙΔΕΑ statement.

Possible tasks for this project :

Go through the EAT workshop, extending the existing AT testsuites, creating a new testsuite using the AT Structures, apply to android new projects, etc (the contributors should make their proposals)

Github repo: https://github.com/EAT-JBCOMMUNITY/EAT

Contact / potential mentors: Panagiotis Sotiropoulos (psotirop@redhat.com)

Associated JBoss community project: EAT

AQAvit - Deep AQAtik

Summary of idea:

A project for applying Machine Learning to large amounts of verification data and matching fresh test failures with existing open/reported issues. This work can be broken down into manageable pieces. The first part is to find a best fitting ‘list of open issues’ that matches a test failure - take our existing code that is using a particular model and try the same approach but varying the model to measure which models gives the most accurate matches with existing issues. This can be fairly open-ended work, but we will also engage the larger community at the project for input as well as involve the contributors in additional learning and research as well as consultation with data scientists.

After some experimentation with this, and having used the contents of various repositories (through queries to Github API to search through issues), the second piece can be to extrapolate this approach to an extended search through other content sources.

Small amount of initial work already completed: https://github.com/adoptium/aqa-test-tools/wiki/Outreachy-TRSS-Machine-Learning-Project:-Deep-AQAtik

Knowledge prerequisite: Machine learning basics, Python, Flask, Anaconda, data visualization

Github repo: https://github.com/adoptium/aqa-test-tools

Project size: medium (~175 hours) 

Skill level: Intermediate/Advanced

Contact(s) / potential mentors(s): Shelley Lambert (slambert@redhat.com), Lan Xia (lan_xia@ca.ibm.com), Longyu Zhang (longyu.zhang@ibm.com)

Associated JBoss community project(s): Adoptium/AQAvit

Drools – Antlr4 based DRL parser

Summary of idea:

Drools has its own language to define a set of rules called DRL, see https://docs.jboss.org/drools/release/latest/drools-docs/html_single/#drl-rules-con_drl-rules

The parser internally used for this language is at the moment a legacy mix of antlr3 plus tons of handwritten code. We want to migrate this parser to one implemented with antlr4 for a twofold reason

• the current parser is becoming old and very hard to maintain and evolve
• on top of this new antlr4 based parser we want to finally implement a decent DRL text editor using the Language Server Protocol and providing code completion through antlr4-c3. 

A first, very incomplete, draft implementation of both the antlr4 based parser and the LSP server are available here https://github.com/mariofusco/drools-lsp Of course it will be moved into drools code base when ready, replacing the existing parser and checking with the entire Drools test suite that it hasn't any regression.

Knowledge pre-requisite: Java, antlr4

Github repo: https://github.com/mariofusco/drools-lsp

Project size: large (~350 hours)

Skill level: Advanced

Contact(s) / potential mentors(s): Mario Fusco <mfusco@redhat.com>

Associated JBoss community project(s): Drools

Quarkus  - API validation and tracking for Quarkus and Quarkiverse

Summary of idea:

Quarkus does timeboxed releases every 4 to 6 weeks which includes Quarkus core and 180+ extensions. We aim for not breaking users and extensions writers but we also don’t want to stand still and not be able to innovate. Today we manually maintain a migration wiki page on what needs migrating if anything between releases. Project idea is to utilize the already existing revapi.org setup and expand it to properly detect and generate documentation for api breakages in a way that help users and extension writers.

When this is done it will be a key central element in Quarkus releases and used heavily across all extensions. If done right it will have a massive impact on enabling Quarkus to continue to innovate.

Expected Technologies to be used: revapi.org, java, quarkus, asciidoctor

Contributor Tasks

- Learn to use revapi

- Enhance the current revapi reporting to be useful

- Automate revapi usage in Quarkus CI build

- Document and script for daily usage of revapi

Stretch goals:

- Implement additonal revapi checks for i.e. property, library and configuraton changes

Contributor Benefits

You will get to work with one of the fastest growing Java frameworks in newer times.

You will work with a 100% remote and distributed team.

You will learn about how to write frameworks, how to keep API stable and how to evolve them.

When successful this revapi integration will have many year impact on ensuring Quarkus development team and users will be able to upgrade and migrate for years to come. It will be used daily by development team and on each monthly release of Quarkus the whole ecosystem will benefit from this work. 

Knowledge pre-requisite: Java

Github repo: https://github.com/quarkusio/quarkus

Project size: large (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Max Rydahl Andersen <manderse@redhat.com>, Lukas Krejci <lkrejci@redhat.com>

Associated JBoss community project(s): Quarkus

WildFly Elytron - TLS Enhancements

Summary of idea:

If you want to learn about security, this is your chance to develop a new security feature for the WildFly Application Server! As a bonus, you'll get to work with a diverse team.

The WildFly Elytron project is a security framework for Java clients and application servers. WildFly is an open source application server. Elytron is used by the WildFly application server to secure applications that are deployed to the server and to secure management access to the server. Banks, retail stores, and governments are just some examples of end-users of the enterprise version of the WildFly application server.

The TLS protocol allows communication between a client and a server to be encrypted. WildFly Elytron allows users to configure policy information related to TLS. Currently, this includes things like key managers, trust managers, cipher suites, and protocols (see https://github.com/wildfly-security/wildfly-elytron/tree/1.x/ssl/src/main/java/org/wildfly/security/ssl).

The purpose of this project is to work on new TLS features for WildFly Elytron. In particular, the goals of this project are to:

• Add support for Online Certificate Status Protocol (OCSP) stapling to WildFly Elytron, for use in the WildFly application server
  • OCSP stapling is a standard that’s used to check the revocation status of an X.509 certificate. In particular, when presenting its certificate during a TLS handshake, the server first sends an OCSP request to an OCSP responder and the returned response is “stapled” to the server’s certificate chain. Because the server is the one contacting the OCSP responder instead of the client, the advantage is that the server bears the resource cost and the OCSP response it receives can be cached and used multiple times for different clients.
• Add support for client side smart cards to the WildFly Elytron Client
  • The WildFly Elytron Client allows remote clients to authenticate using Elytron. The WildFly Elytron Client configuration already allows SSL contexts to be configured, allowing a remote client to specify a key store that can be used to obtain the client certificate to present during a TLS connection. A missing feature is the ability to obtain the client certificate to be used from a client side smart card. As an example, consider the case where an administrator would like to connect to the WildFly CLI using a smart card. The administrator would insert their smart card into their machine and connect to the CLI using the WildFly Elytron Client. The WildFly Elytron Client would need to prompt the administrator in order to obtain the PIN to be used to unlock the smart card and obtain the certificate to present during a TLS connection.
• Note: The two goals above are intended for a large project (~350 hours). If you’d prefer to work on a medium project (~175 hours), we’d recommend only focusing on the support for OCSP stapling.

Possible tasks for this project, broken down by the two goals described above:

• Add support for OCSP stapling
  • Create a document that describes how you plan to approach the problem.
  • Implement the ability for a WildFly server to use OCSP stapling when presenting its certificate. This will involve adding functionality to both the WildFly Elytron project as well as the WildFly Core project, where Elytron is actually integrated with the WildFly application server.
  • Implement appropriate test cases.
  • Write documentation.
  • Create a blog post that gives an overview of your project.
• Add support for client side smart cards
  • Create a document that describes how you plan to approach the problem.
  • Implement the ability for the WildFly Elytron Client to obtain the certificate to be used during a TLS connection from a smart card. The WildFly Elytron Client will need to be able to prompt the user for the PIN to use to unlock the smart card.
  • Implement appropriate test cases.
  • Write documentation.
  • Create a blog post that gives an overview of your project.

The WildFly Elytron team is a diverse, distributed team that has a lot of experience working with interns and junior engineers.

Knowledge pre-requisites:

• Experience with Java
• Git
• Maven

GitHub repo: https://github.com/wildfly-security/wildfly-elytron

Other useful links: 

• Contribution Guide
• Elytron Website
• Getting Started Guide

Project size: Medium (~175 hours) or large (~350 hours) depending on whether you’d like to tackle only one feature or both features

Skill level: Intermediate

Project chat: https://wildfly.zulipchat.com/#narrow/stream/173102-wildfly-elytron

Contact(s) / potential mentors(s): Farah Juma <fjuma@redhat.com> and Diana Krepinska <dvilkola@redhat.com>

Associated JBoss community project(s): Elytron, WildFly

Kruize Autotune - ML Based Workload classification

Summary of idea:

Kruize Autotune is a Performance Tuning Tool for Kubernetes. https://github.com/kruize/autotune. It uses Hyper Parameter Optimization to tune the language runtime layers of a given application.

This project will attempt to use Machine Learning to classify the incoming load as well as classify the target application type. The classification will help us to make better configuration recommendations for performance objectives as well as reduce the time taken to provide those recommendations. Currently it takes more than 24 hours to provide a recommendation using bayesian optimization and this is for a fixed incoming load. Classification of incoming load will help us to handle diverse load conditions and classification of the application type can help us to narrow down on the right set of tunables. The goal of this project is to explore various classification algorithms and arrive at a framework that best suits the needs of the Autotune project.

Knowledge prerequisite: Machine Learning basics, Python, Java, Container and Kubernetes basics

Github repo: https://github.com/kruize/autotune

Project Size: large (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentor(s): Dinakar Guniguntala <dgunigun@redhat.com>, Sanjay Arora <saarora@redhat.com>

Associated JBoss community project(s): Quarkus. 

Other related Open Source Project(s): Kubernetes, Minikube, Prometheus, OpenShift

Flotta  - Reduce energy consumption

Summary of idea: Reduce power consumption on Flotta device agent on small factor edge devices

-Idea

Flotta-device agent is handling all the workloads on small factor SBC, like RaspberryPI, Nvidia Jetson Boards, etc.. These SBCs can be located anywhere, where the power or network cannot be reliable. 

Some devices are running on moving devices or powered by solar panels, where power consumption is a key factor.

  
Features that will try to achieve:

• Workloads on low-energy profile: Have a way to detect that there is not enough energy to be used, and stop/reduce workloads based on users needs. 
• Device Agent consumption: Monitoring and auditing the code, and look for ways to improve the energy consumption and ways to decrease the energy footprint.
• Operating system audit: added a way to enable/disable kernel modules based on the power consumption.

Knowledge prerequisite: 

• Linux OS 
• Golang for the device agent daemon.

Github repo: https://github.com/project-flotta

Project size: medium (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Eloy Coto Pereiro ecotoper@redhat.com

Flotta - WASM workloads

Summary of idea:  Running WASM workloads on small factor devices

-Idea

At the moment, the flotta-project can run container workloads on any device. One of the things that we want to achieve is running other types of workloads. Web assembly (WASM) is a technology that provides a way to run workloads that users can write with multiple programming languages. 

  
Features that will try to achieve:

• WASM workload running: running workload on any device, that can be x86 or ARM based devices.

• WASM workload security policies: a way to run WASM modules in the device, without compromising other workload or base operating system. 

Knowledge prerequisite: 

• Golang
• Web Assembly internals. 

Github repo: https://github.com/project-flotta

Project size: medium (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Eloy Coto Pereiro ecotoper@redhat.com

Flotta- Edge example application

Summary of idea: edge devices demo

-Idea

It would be great to have an example application which would run on a bunch of devices collecting video streams/pictures from webcam with some analysis on the device. Later it is sent to the cluster and presented (UI).

Features that will try to achieve:

• Running a workload container to collect/process input from webcam with basic processing capabilities
• Running cluster side container app which would present aggregated results 

Knowledge prerequisite: 

• Golang for containerized app running on the device
• Any web framework for presentation running in the cluster
• Basic k8s/ocp knowledge

Github repo: https://github.com/project-flotta

Project size: medium (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Piotr Kliczewski pkliczew@redhat.com

Flotta- Sense the Internet

Summary of idea: 

-Idea

Flotta-device agent handles workloads on low resource devices like RaspberryPI, Nvidia Jetson Boards, etc. These devices can be located anywhere.

The goal is to investigate the Internet network topology and measure the performance of the network using devices managed by flotta.

The flotta-devices must perform large-scale topology discovery efficiently, both at the IP level and at the router level. In addition, the devices should sense the quality of the network using active probing tools (i.e. traceroute, ICMP, ping). Later devices share information regarding the paths they have explored to the cluster and presented (UI).

Features that will try to achieve:

• IP level network topology discovery: sense the network using both IPv4 and IPv6.
• Router level network topology discovery: sense the network using IP Alias resolution techniques.

Knowledge prerequisite: 

• Golang for containerized app running on the device
• Basic k8s/ocp knowledge
• Basic networking knowledge
• Linux OS

Github repo: https://github.com/project-flotta

Project size: medium (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Gloria Ciavarrini gciavarrini@redhat.com

Infinispan and Quarkus  - Multimap enhancements and support

Summary of idea:

Multimap is a data structure that has gotten the attention from Infinispan users. The structure today lacks evolutions and support of features and new API of Infinispan:

• Search and query support
• REST API support
• Not supporting duplicates
• Reactive API integration and development
• Integration with Quarkus through the extension

Expected Technologies to be used: java, infinispan, quarkus

Contributor Tasks

- Evolve Multimap data structure in Infinispan

- Enhance the current API in Quarkus

- Evolve tutorials

Contributor Benefits

You will learn how to implement a Data structure like Multimap and add new features as well as integrating with other notorious frameworks like Quarkus.

You will work with a 100% remote and distributed team.

You will learn about how to write frameworks, how to keep API stable and how to evolve them.

Knowledge pre-requisite: Java

Github repo Infinispan: https://github.com/infinispan/ 

Github repo Quarkus: https://github.com/quarkusio/ 

Project size: large (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Katia Aresti <karesti@redhat.com>, Tristan Tarrant<ttarrant@redhat.com>

Associated JBoss community project(s): Quarkus

Infinispan and NodeJS  - NodeJS client evolutions

Summary of idea:

Java

• Sear

Expected Technologies to be used: java, infinispan, quarkus

Contributor Tasks

- Evolve

Contributor Benefits

You will learn how to implement

Knowledge pre-requisite: Java

Github repo Infinispan: https://github.com/infinispan/js-client/ 

Github repo Quarkus: https://github.com/quarkusio/ 

Project size: large (~350 hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Katia Aresti <karesti@redhat.com>, Tristan Tarrant<ttarrant@redhat.com>

Associated JBoss community project(s): Quarkus