...
Associated JBoss community project(s): Drogue IoT
...
EAT - Testing Infinite Software Project Versions
Summary of idea:
In Drogue IoT we have an example/demo/PoC, which implements a voice assistant based on our Drogue IoT cloud deployment. There is wake-word/keyword/trigger-word detection, which initiates the audio recording. Once the snippet is recorded it will be processed by a speech-to-text backend and is further processed.
For the wake-word detection we are currently using Pocketsphinx. However, the detection rate is pretty bad. Also it doesn't run on embedded devices.
The outcome of the project should be to use Tensforflow (Lite) to create a model for wake word detection. Additionally a program (script) which continuously listens to audio input (microphone). Once the trigger is detected, it records for up to X seconds, or until it detects silence. A single command is sufficient ("hey rodney"), no full speech-to-text model is required. It is perfectly fine to re-use existing data sets and scripts, as long as they are open source, and we can build this ourselves.
This should be able to run on a Raspberry Pi like device, with the prospect of being able to run on embedded devices (microcontroller) using Tensorflow Lite. Bonus points for actually porting that to a micro-controller, but that is not required.
Knowledge prerequisite:
- AI/ML - Tensorflow
- Python (probably)
- Linux
- Embedded programming (optionally)
Github repo: https://github.com/drogue-iot/drogue-cloud, https://github.com/drogue-iot/hey-rodney
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, 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
Drools - Executable Model Compiler 2.0
Summary of the idea:
Drools is a business rules management system that allows developers and business analysts to write business rules in an easy way and to evaluate such rules in the fastest way possible. With the “executable model” we provided a Java DSL to write such rules in a typesafe way, leveraging the javac compilation to get fast startup time while instantiating the engine. The original DRL (Drools Rules Syntax) language is supported: we provide a compiler to compile the DRL to Java Code.
The original executable model compiler needs some improvement: the idea is to generate the executable model code in the fastest way possible.
We targeted correctness rather than speed in 1.0, and by rewriting the type checker and leveraging a multi phase approach we could theoretically support parallel compilation. We also have some known performance issues in lambda externalisation - as it’s implemented as a post processing phase it adds extra time to the compilation. We’d love to have a performance oriented approach, in which we measure the build time from the start so that it should be easier to track the wanted speed. Correctness is guaranteed by the current test suite that should be supported 100%. We should avoid JavaParser AST generation in the processing phase, as its AST is not optimized for sharing and cloning it’s an expensive operation.
Project references:
http://blog.athico.com/2018/02/the-drools-executable-model-is-alive.html
Knowledge Prerequisite:
- The Java Programming Language
- Basic understanding of Pattern Matching
- Basic understanding of Rule Engine
Skill Level: Intermediate
Contact: Luca Molteni (lmolteni@redhat.com)
GitHub:
https://github.com/kiegroup/drools
Associated JBoss community project(s): https://drools.org
3scale - Envoy proxy authorization cache
Summary of idea:
3scale is an API management platform that provides API lifecycle management, access control, developer portal, and gateway integration. This project aims to implement an authorization cache locally accessible from Envoy proxy-wasm modules that contains 3scale-specific knowledge to intelligently cache request authorization results in order to minimize request latencies while keeping the 3scale control plane periodically synchronized.
As with many cache implementations, there are trade-offs to be made. In this case we strongly lean towards lower latencies rather than high accuracy, so we can take some design decisions that leverage this fact. The main goal of this cache layer is that it becomes usable locally from proxy-wasm modules, but having it also work standalone deployed as a separate HTTP or gRPC service is a nice extra. Having it return information to the caller so that a proxy can return rate-limiting headers is a requirement. Learning about the 3scale data model and its Service Management API is part of the learning process involved in this project.
References:
- Proxy-WASM: https://github.com/proxy-wasm/spec, talk: https://bit.ly/3a22R5B
- Design document for a similar authorization cache: https://github.com/3scale/3scale-authorizer/blob/master/pkg/backend/v1/docs/README.md
- Rate-limiting headers IETF draft: https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
Knowledge Prerequisite:
- Basic Envoy proxy knowledge
- Rust
- gRPC (optional)
- WebAssembly (optional)
Github organization: https://github.com/3scale
Skill level: Intermediate
Contact(s) / potential mentors(s): Alex Martinez Ruiz (amr@redhat.com)
Associated JBoss community project(s): 3scale API Management
AeroGear - Apache Kafka and GraphQL quick-starts
Summary of idea:
Apache Kafka is a popular messaging platform that can be used to build reactive backends.
This project aims to provide sample applications (quickstarts) for various programming languages that will use:
- Postgres (or MongoDb) Databases
- GraphQL Subscriptions
- Apache Kafka for eventing (might use Debezium for database driven events)
...
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, 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
Drools - Executable Model Compiler 2.0
Summary of the idea:
Drools is a business rules management system that allows developers and business analysts to write business rules in an easy way and to evaluate such rules in the fastest way possible. With the “executable model” we provided a Java DSL to write such rules in a typesafe way, leveraging the javac compilation to get fast startup time while instantiating the engine. The original DRL (Drools Rules Syntax) language is supported: we provide a compiler to compile the DRL to Java Code.
The original executable model compiler needs some improvement: the idea is to generate the executable model code in the fastest way possible.
We targeted correctness rather than speed in 1.0, and by rewriting the type checker and leveraging a multi phase approach we could theoretically support parallel compilation. We also have some known performance issues in lambda externalisation - as it’s implemented as a post processing phase it adds extra time to the compilation. We’d love to have a performance oriented approach, in which we measure the build time from the start so that it should be easier to track the wanted speed. Correctness is guaranteed by the current test suite that should be supported 100%. We should avoid JavaParser AST generation in the processing phase, as its AST is not optimized for sharing and cloning it’s an expensive operation.
Project references:
http://blog.athico.com/2018/02/the-drools-executable-model-is-alive.html
Knowledge Prerequisite:
- The Java Programming Language
- Basic understanding of Pattern Matching
- Basic understanding of Rule Engine
Skill Level: Intermediate
Contact: Luca Molteni (lmolteni@redhat.com)
GitHub:
https://github.com/kiegroup/drools
Associated JBoss community project(s): https://drools.org
3scale - Envoy proxy authorization cache
Summary of idea:
3scale is an API management platform that provides API lifecycle management, access control, developer portal, and gateway integration. This project aims to implement an authorization cache locally accessible from Envoy proxy-wasm modules that contains 3scale-specific knowledge to intelligently cache request authorization results in order to minimize request latencies while keeping the 3scale control plane periodically synchronized.
As with many cache implementations, there are trade-offs to be made. In this case we strongly lean towards lower latencies rather than high accuracy, so we can take some design decisions that leverage this fact. The main goal of this cache layer is that it becomes usable locally from proxy-wasm modules, but having it also work standalone deployed as a separate HTTP or gRPC service is a nice extra. Having it return information to the caller so that a proxy can return rate-limiting headers is a requirement. Learning about the 3scale data model and its Service Management API is part of the learning process involved in this project.
References:
- Proxy-WASM: https://github.com/proxy-wasm/spec, talk: https://bit.ly/3a22R5B
- Design document for a similar authorization cache: https://github.com/3scale/3scale-authorizer/blob/master/pkg/backend/v1/docs/README.md
- Rate-limiting headers IETF draft: https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
Knowledge Prerequisite:
- Basic Envoy proxy knowledge
- Rust
- gRPC (optional)
- WebAssembly (optional)
Github organization: https://github.com/3scale
Skill level: Intermediate
Contact(s) / potential mentors(s): Alex Martinez Ruiz (amr@redhat.com)
Associated JBoss community project(s): 3scale API Management
AeroGear - Apache Kafka and GraphQL quick-starts
Summary of idea:
Apache Kafka is a popular messaging platform that can be used to build reactive backends.
This project aims to provide sample applications (quickstarts) for various programming languages that will use:
- Postgres (or MongoDb) Databases
- GraphQL Subscriptions
- Apache Kafka for eventing (might use Debezium for database driven events)
Candidates would also need to provide the modular architecture of the examples so they can be consumed with both REST (ServerSent events) and GraphQL subscriptions.
Knowledge prerequisite:
- Knowledge one of the languages used to write example (Node.js, Python, Golang, Kotlin, ?)
- Basic understanding of reactive programming
- Knowledge of GraphQL
- Familiarity AeroGear community projects like https://graphback.dev
Github org: https://github.com/aerogear
Skill level: Beginner
Project Chat: https://discord.com/invite/mJ7j84m
Contact(s) / potential mentors(s): Wojciech Trocki (wtr@redhat.com)
Associated JBoss community project(s): AeroGear
AeroGear - KNative "Herd" CLI
Summary of idea:
Knative is an serverless platform offering ability to deploy your projects to kubernetes.
In this project we would like to explore ability to build lighweight framework for connecting multiple serverless functions with underlying services and API gateway.
Candidates can work on providing new abstraction on top of the KNative offering ability to create "herd" of functions that can be written in more than one language.
Developers can provide custom configuration for functions and build wrapper for KNative CLI offering simplicity to build and deploy multiple functions as single application.
Serverless functions that can be automatically added to the API gateway serving both GraphQL and Rest endpoints.
Suggested languages that can be used for building this ecosystem:
- Node.js
- Quarkus (Java)
- Golang
- Python
Candidates would also need to provide examples of using eventing and database access for at least 1 of the languages.
Knowledge prerequisite:
- Knowledge one of the languages (Node.js, Python, Golang, Kotlin, ?)
- Basic understanding of KNative
- Knowledge of GraphQL
- Familiarity AeroGear community projects like https://graphback.dev
Github org: https://github.com/aerogear
Skill level: Intermediate
Knowledge prerequisite:
- Knowledge one of the languages used to write example (Node.js, Python, Golang, Kotlin, ?)
- Basic understanding of reactive programming
- Knowledge of GraphQL
- Familiarity AeroGear community projects like https://graphback.dev
Github org: https://github.com/aerogear
Skill level: Beginner
Project Chat: https://discord.com/invite/mJ7j84m
...
Associated JBoss community project(s): AeroGear
...
Debezium Schema History Compaction Tool
Summary of idea:Knative
Debezium is an serverless platform offering ability to deploy your projects to kubernetes.
In this project we would like to explore ability to build lighweight framework for connecting multiple serverless functions with underlying services and API gateway.
Candidates can work on providing new abstraction on top of the KNative offering ability to create "herd" of functions that can be written in more than one language.
Developers can provide custom configuration for functions and build wrapper for KNative CLI offering simplicity to build and deploy multiple functions as single application.Serverless functions that can be automatically added to the API gateway serving both GraphQL and Rest endpoints.
Suggested languages that can be used for building this ecosystem:
- Node.js
- Quarkus (Java)
- Golang
- Python
Candidates would also need to provide examples of using eventing and database access for at least 1 of the languages.
Knowledge prerequisite:
- Knowledge one of the languages (Node.js, Python, Golang, Kotlin, ?)
- Basic understanding of KNative
- Knowledge of GraphQL
- Familiarity AeroGear community projects like https://graphback.dev
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.
Your mission, should you decide to accept it, will be:
- 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 represntation 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.
Knowledge prerequisite: Java, Git, Maven, at least one of the databases supported by Debezium
Github repoGithub org: https://github.com/debezium/aerogeardebezium
Skill level: IntermediateProject Chat: https://discord.com/invite/mJ7j84m/Advanced
Contact(s) / potential mentors(s): Wojciech Trocki (wtr@redhat.Gunnar Morling (gmorling AT redhat DOT com)
Associated JBoss community project(s): AeroGear 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 provide a port the existing stand-alone tool main class for compacting the schema history topic used by several Debezium connectorsthe Debezium Cassandra connector to Debezium Server as its runtime environment.
Your mission, should you decide to accept it, will be:
- 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 (
- 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 represntation 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 the connector can be used after this re-implementation
See Jira issue DBZ-7472098 for further details of this project idea.
Knowledge prerequisite: Java, Git, Maven, at least one of the databases supported by Debezium; ideally Cassandra
Github repo: https://github.com/debezium/debezium
...
Associated JBoss community project(s): Debezium
...
Knative Autoscaling: Experiment with different algorithms and improve the existing one
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.
Your mission, should you decide to accept it, will be:
- 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.
Knative Serving is a building block for creating a Serverless platform on top of Kubernetes. Its scaling capabilities are among the most important features. However, Kubernetes is not necessarily easy to deal with, when it comes to scaling pods especially if you want to minimize the so called cold-start latencies (a request having to wait until an entire container is spun up), that customers have to take.
Currently, Knative Serving collects traffic metrics from various sources, aggregates them by taking an average over all datapoints and generates its recommendation based on the resulting data.
Your mission is to come up with a much finer hammer than "average the data" that takes the Kubernetes environment into account (i.e. scales down slower than it scales up) and to make sure that the new algorithm doesn't break users of the existing algorithm. As such, the creation of a great experimentation harness will be necessary.
- Understand and analyze the environment (Kubernetes, Knative, Serverless) and understand the characteristics that the algorithm has to have.
- Create an experimentation harness that allows you (and us) to play with different algorithms.
- With that harness, come up with an improvement over the current algorithm.
Knowledge prerequisite: Golang, Statistics, Serverless/FaaS (optional), Kubernetes (optional)Knowledge prerequisite: Java, Git, Maven; ideally Cassandra
Github repo: https://github.com/knative/debeziumserving/debezium
Skill level: Intermediate/Advanced
Contact(s) Gunnar Morling (gmorling / potential mentors(s): Markus Thoemmes (mthoemmes AT redhat DOT com)
Associated JBoss community project(s): Debezium
Knative Autoscaling: Experiment with different algorithms and improve the existing one
Summary of idea:
Knative Serving is a building block for creating a Serverless platform on top of Kubernetes. Its scaling capabilities are among the most important features. However, Kubernetes is not necessarily easy to deal with, when it comes to scaling pods especially if you want to minimize the so called cold-start latencies (a request having to wait until an entire container is spun up), that customers have to take.
Currently, Knative Serving collects traffic metrics from various sources, aggregates them by taking an average over all datapoints and generates its recommendation based on the resulting data.
Your mission is to come up with a much finer hammer than "average the data" that takes the Kubernetes environment into account (i.e. scales down slower than it scales up) and to make sure that the new algorithm doesn't break users of the existing algorithm. As such, the creation of a great experimentation harness will be necessary.
- Understand and analyze the environment (Kubernetes, Knative, Serverless) and understand the characteristics that the algorithm has to have.
- Create an experimentation harness that allows you (and us) to play with different algorithms.
- With that harness, come up with an improvement over the current algorithm.
Create JWS Openshift Operator in Java
Summary of idea:
JWS can be deployed in Openshift via the JWS Operator. Currently, JWS Openshift operator is written in Golang using the operator-sdk. The mission of this project is to study and develop JWS Operator in Java, using java-operator-sdk (https://github.com/java-operator-sdk/java-operator-sdk).
Students can get the main idea from our Golang operator which is here: https://github.com/web-servers/jws-operator and adapt its functionality to the new java-operator-sdk based one.
Knowledge prerequisite: Java, Golang, Kubernetes/Openshift, OperatorsKnowledge prerequisite: Golang, Statistics, Serverless/FaaS (optional), Kubernetes (optional)
Github repo: https://github.com/knative/serving/web-servers/jws-operator
Skill level: Intermediate/Advanced
Contact(s) / potential mentors(s): Markus Thoemmes (mthoemmes Jean-Frederic Clere (jfclere AT redhat DOT com), George Zaronikas (gzaronik AT redhat DOT com)