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

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.

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 students 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 students 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>

Associated JBoss community project(s): Quarkus