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 :

• extend the existing AT testsuites with latest JBOSS Community server snapshot
• apply to android new projects (relevant to EAT)
• the contributors are also welcome to make their proposals
  

Project size: large (~350 hours)

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: large (~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: large (~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:

The Infinispan NodeJS client does not support all the media types of caches in the Infinispan server, and does not support search and other features.

Make evolutions to the NodeJS client low lever library to make it possible to improve the API with Typescript

• Support Protobuf encoded caches
• Support Search 
• Improve API with Typescript

Expected Technologies to be used: javascript and nodejs

Contributor Tasks

- Evolve the Javascript NodeJS client for Infinispan

- Design a better API with TypeScript

Contributor Benefits

You will learn how to implement a low level library with Javascript and TypeScript and how to assure the quality and API design.

Knowledge pre-requisite: Javascript, NodeJS

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

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): Infinispan

Infinispan and C#  - Distributed Cache for ASP .Net Core

Summary of idea

The Infinispan C# client provides a rich set of features to do distributed caching in user applications, but it doesn't currently offer a seamless integration with the .NET Core caching framework.

To improve this aspect, an implementation of the IDistributedCache interface should be provided so that the user can just inject the cache in its application using the .NET Core framework.

Contributor Tasks

Provide an implementation of the Microsoft.Extensions.Caching.Distributed.IDistributedCache interface based on the Infinispan C# .Net Core Client.

Contributor Benefits

You will do C# coding experience and will become familiar with caching, both on .NET Core and Infinispan side.

Knowledge Pre-requisite

C#, .NET Core

Github project

https://github.com/infinispan/Infinispan.Hotrod.Core

Project size: medium (175~hours)

Skill level: Intermediate

Contact(s) / potential mentors(s): Vittorio Rigamonti <vrigamon@redhat.com>, Tristan Tarrant<ttarrant@redhat.com>

Associated JBoss community project(s): Infinispan

Debezium - Schema History Compaction Tool

Summary of idea

Debezium is an open-source platform for change data capture (CDC) and lets you stream data change events out of a variety of databases such as MySQL, Postgres, SQL Server, MongoDB, and others. The idea of this proposal is to provide a stand-alone tool for compacting the schema history topic used by several Debezium connectors.

Contributor Tasks

• Develop a tool – based on the Quarkus stack – which "compacts" a given schema history topic; this tool should
  • Read a schema history topic from the beginning
  • Build up the in-memory representation of the database schema
  • Serialize that schema into a new topic, only containing the current state of the schema
• Test that tool
• Document the usage of the tool, e.g. describing how to re-configure associated connectors, so to make use of the compacted topic, etc.
• Create a demo (e.g. as a video) and blog post-show-casing how that tool can be used
• See Jira issue DBZ-747 for further details of this project idea.

Contributor Benefits

You will learn how to build a Quarkus-based application, gain a basic understanding of Apache Kafka, and see how Debezium interfaces with Apache Kafka.

Knowledge Pre-requisite

Java, Git, Maven, and at least one of the databases supported by Debezium

Project Details

Github repo: https://github.com/debezium/debezium

Project size: medium (~175 hours)

Skill level: Intermediate/Advanced

Contact(s) Chris Cranford (ccranfor AT redhat DOT com), Gunnar Morling (gmorling AT redhat DOT com)

Associated JBoss community project(s): Debezium

Debezium - Porting the Debezium Cassandra Connector to Debezium Server

Summary of idea

Debezium is an open-source platform for change data capture (CDC) and lets you stream data change events out of a variety of databases such as MySQL, Postgres, SQL Server, MongoDB, and others. The idea of this proposal is to port the existing stand-alone main class for the Debezium Cassandra connector to Debezium Server as its runtime environment.

Contributor tasks

• Implement an outbound adaptor for Debezium Server which sends change events to Apache Kafka (similar to the existing adaptors for Apache Pulsar, Amazon Kinesis, Google Cloud Pub/Sub etc.)
• Replace the existing stand-alone main class with the Debezium Server runtime
  • Adapt Debezium Server, so that it not only can be used with the Kafka Connect based Debezium connectors but also with the Cassandra connector implementation
  • Replace means of configuration with those of Debezium Server (application.properties file, etc.)
  • Update tests and documentation accordingly
• Optional: Refactor the Cassandra connector implementation to make use of Debezium's common connector framework as far as possible
• Create a demo (e.g. as a video) and blog post-show-casing how the connector can be used after this re-implementation
• See Jira issue DBZ-2098 for further details of this project idea.

Contributor Benefits

You will gain experience working with Debezium Server, a Quarkus-based application, how Debezium integrates with Cassandra including but not limited to the Debezium CDC connector pipeline.

Knowledge Pre-requisite

Java, Git, Maven; ideally Cassandra

Project Details

Github repo: https://github.com/debezium/debezium, https://github.com/debezium/debezium-connector-cassandra

Project size: large (~350 hours)

Skill level: Intermediate/Advanced

Contact(s) Chris Cranford (ccranfor AT redhat DOT com), Gunnar Morling (gmorling AT redhat DOT com)

Associated JBoss community project(s): Debezium

Debezium - Implementing a JDBC Sink connector

Summary of idea

Debezium is an open-source platform for change data capture (CDC) and lets you stream data change events out of a variety of databases such as MySQL, Postgres, SQL Server, MongoDB, and others. The idea of this proposal is to build out a multi-task, schema-evolution-aware JDBC Kafka Connect sink connector that is capable of ingesting Debezium CDC events and applying those changes to the sink relational database.

Contributor tasks

• Build upon the existing work in this pull request to flush out a fully functional JDBC sink connector
  • Use Hibernate and JDBC to write CDC changes ingested from Kafka Topics to the destination/sink database.
  • Implement behavior to support evolving the destination schema as the source schema changes.
  • Optional: implement multi-task aware support for the sink connector
• Create a demo (e.g. as a video) and blog post-show-casing how the sink connector can be used to replicate changes from a source to a destination database
• See Jira issue DBZ-3647 for further details of this project idea.

Contributor Benefits

You will gain experience working with Debezium, understanding its CDC pipeline, relational databases, and how Debezium integrates with Apache Kafka Connect and Apache Kafka frameworks.

Knowledge Pre-requisite

Java, Git, Maven, JDBC, Hibernate; ideally at least one relational database that Debezium Supports.

Project Details

Github repo: https://github.com/debezium/debezium, https://github.com/debezium/debezium-jdbc-sink/

Project size: medium (~350 hours)

Skill level: Intermediate/Advanced

Contact(s) Chris Cranford (ccranfor AT redhat DOT com), Gunnar Morling (gmorling AT redhat DOT com)

Associated JBoss community project(s): Debezium