Provide a functionality in the admin console (and from REST) that allows one to view the XML configuration of an individual item. For example, an user would be interested in seeing the XML representation of the new configuration parameter, or it might be a user object, group, provisioning rules, etc.

Difficulty: Major

Potential mentors:

Andrea Patricelli, mail: andrea.patricelli (at) apache.org

Project Devs, mail:

...

GSOC: Varnish Cache support in Apache Traffic Control

Background
Apache Traffic Control is a Content Delivery Network (CDN) control plane for large scale content distribution.

Traffic Control currently requires Apache Traffic Server as the underlying cache. Help us expand the scope by integrating with the very popular Varnish Cache.

There are multiple aspects to this project:

Configuration Generation: Write software to build Varnish configuration files (VCL). This code will be implemented in our Traffic Ops and cache client side utilities, both written in Go.

Health Monitoring: Implement monitoring of the Varnish cache health and performance. This code will run both in the Traffic Monitor component and within Varnish. Traffic Monitor is written in Go and Varnish is written in C.

Testing: Adding automated tests for new code

Skills:

Proficiency in Go is required
A basic knowledge of HTTP and caching is preferred, but not required for this project.

Difficulty: Major

Potential mentors:

Eric Friedrich, mail: friede (at) apache.org

Project Devs, mail: dev (at) trafficcontrol.apache.org

Clerezza

Implement a Secure Scuttlebutt Server

Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. The Scuttlebutt Protocol Guide can be found here: https://ssbc.github.io/scuttlebutt-protocol-guide/. Starting from this link https://handbook.scuttlebutt.nz/ you can acquire quite a lot knowledge of the SSB protocol and orientations from the conceptual to the practical aspects of writing and using SSB based applications.

The task of this issue is to implement the functionality of an SSB server as done in JavaScript by https://github.com/ssbc/ssb-server, but using Apache Tuweni (Incubating) for the handshake and an Apache Clerezza based triple store for storing and querying the messages. Apache Tuweni (https://tuweni.apache.org/) is a set of libraries and other tools to aid development of blockchain and other decentralized software in Java and other JVM languages.

For those who are interested in getting more detail about SSB’s features and its operations, see also the paper titled "Secure Scuttlebutt: An Identity-Centric Protocol for Subjective and Decentralized Applications" attached in this issue.

Difficulty: Major

Potential mentors:

Furkan Kamaci, mail: kamaci (at) apache.org

Project Devs, mail:

Library for Messaging App Storage

Nowadays, more and more companies are using a messaging app to communicate with their customers. The conversations contain not only information about customer engagements and requests, but may reveal interesting facts relevant for product marketing when analysed using business intelligent tools. Thus, having those conversations modelled appropriately is of great importance. RDF is surely one suitable format for modelling and storing those conversations.

The purpose of this task is to define an ontology for conversations and to create a Java library based on Apache Clerezza to store them. Signal (https://signal.org/docs/) is one of many messaging apps which is open source. This task recommends to integrate the library to be developed into Signal (https://github.com/signalapp) for testing.

By resolving this task you will learn

RDF
Apache Clerezza
Signal API

CloudStack

CloudStack GSoC 2021 Ideas

Hello Students! We are the Apache CloudStack project. From our project website: "Apache CloudStack is open source software designed to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service (IaaS) cloud computing platform. CloudStack is used by a number of service providers to offer public cloud services, and by many companies to provide an on-premises (private) cloud offering, or as part of a hybrid cloud solution."

2-min video on the Apache CloudStack project - https://www.youtube.com/watch?v=oJ4b8HFmFTc

Here's about an hour-long intro to what is CloudStack - https://www.youtube.com/watch?v=4qFFwyK9hos

The general skills student would need are - Java, Python, JavaScript/Vue. Idea-specific requirements are mentioned on the idea issue. We're a diverse and welcoming community and we encourage interested students to join the dev ML: http://cloudstack.apache.org/mailing-lists.html (dev@cloudstack.apache.org^{Image Added})

All our Apache CloudStack GSoC2021 ideas are tracked on the project's Github issue: https://github.com/apache/cloudstack/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc2021

Feature	Skills Required	Difficulty Level	Potential Mentor(s)	Details and Discussion
Support Multiple SSH Keys for VMs	Java, Javascript/Vue	Medium	David Jumani david.jumani@shapeblue.com^{Image Added}	https://github.com/apache/cloudstack/issues/4813
Clone a Virtual Machine	Java, Javascript/Vue	Medium	Suresh Anaparti sureshanaparti@apache.org^{Image Added}	https://github.com/apache/cloudstack/issues/4818
UI Shortcuts (UX improvements in the UI)	Javascript, Vue	Easy	Boris Stoyanov boris.stoyanov@shapeblue.com^{Image Added} David Jumani david.jumani@shapeblue.com^{Image Added}	https://github.com/apache/cloudstack/issues/4798
CloudStack OAuth2 Plugin	Java, Javascript/Vue	Medium	Nicolas Vazquez nicovazquez90@gmail.com^{Image Added} Rohit Yadav rohit@apache.org^{Image Added}	https://github.com/apache/cloudstack/issues/4834
Synchronization of network devices on newly added hosts for Persistent Networks	Java	Medium	Pearl Dsilva pearl.dsilva@shapeblue.com^{Image Added}	https://github.com/apache/cloudstack/issues/4814
Add SPICE console for vms on KVM/XenServer	Java, Python, Javascript	Hard	Wei Zhou ustcweizhou@gmail.com^{Image Added}	https://github.com/apache/cloudstack/issues/4803
Configuration parameters and APIs mappings	Java, Python	Hard	Harikrishna Patnala harikrishna.patnala@gmail.com^{Image Added}	https://github.com/apache/cloudstack/issues/4825
Add virt-v2v support in CloudStack for VM import to KVM	Java, Python, libvirt, libguestfs	Hard	Rohit Yadav rohit@apache.org^{Image Added}	https://github.com/apache/cloudstack/issues/4696

We have an onboarding course for students to learn and get started with CloudStack:
https://github.com/shapeblue/hackerbook

Project wiki and other resources:
https://cwiki.apache.org/confluence/display/CLOUDSTACK

https://github.com/apache/cloudstack

http://docs.cloudstack.apache.org/

Difficulty: Major

Potential mentors:

Rohit Yadav, mail: bhaisaab

Difficulty: Major

Potential mentors:

Furkan Kamaci, mail: kamaci (at) apache.org

Project Devs, mail:

Cassandra

Add ability to ttl snapshots

It should be possible to add a TTL to snapshots, after which it automatically cleans itself up.

This will be useful together with the auto_snapshot option, where you want to keep an emergency snapshot in case of accidental drop or truncation but automatically remove it after a specified period when it's no longer useful. So in addition to allowing a user to specify a snapshot ttl on nodetool snapshot we should have a auto_snapshot_ttl option that allows a user to set a ttl for automatic snaphots on drop/truncate.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Migrate use of maven-ant-tasks to resolver-ant-tasks

Cassandra resolves dependencies and generates maven pom files through the use of maven-ant-tasks. This is no longer a supported project.

The recommended upgrade is to resolver-ant-tasks. It follows similar APIs so shouldn't be too impactful a change.

The existing maven-ant-tasks has caused some headaches already with internal super poms referencing insecure http:// central maven repository URLs that are no longer supported.

We should also take the opportunity to

define the "test" scope (classpath) for those dependencies only used for tests (currently we are packaging test dependencies into the release binary artefact),
remove the jar files stored in the git repo under the "lib/" folder.

These two above points have to happen in tandem, as the jar files under lib/ are those that get bundled into the build/dist/lib/ and hence the binary artefact. That is, all jar files under lib/ are the project's "compile" scope, and all other dependencies defined in build.xml are either "provided" or "test" scope. These different scopes for dependencies are currently configured in different maven-ant-tasks poms. See https://github.com/apache/cassandra/commit/d43b9ce5092f8879a1a66afebab74d86e9e127fb#r45659668

Difficulty: Normal

Potential mentors:

mck, mail: mck (at) apache.org

Project Devs, mail: dev (at) cassandracloudstack.apache.org

Add Plugin Support for CQLSH

Currently the Cassandra drivers offer a plugin authenticator architecture for the support of different authentication methods. This has been leveraged to provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, cqlsh, the included CLI tool, does not offer such support. Switching to a new enhanced authentication scheme thus means being cut off from using cqlsh in normal operation.

We should have a means of using the same plugins and authentication providers as the Python Cassandra driver.

Here's a link to an initial draft of CEP.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Prevent and fail-fast any attempts to incremental repair cdc/mv tables

Running incremental repairs on CDC or MV tables breaks them.

Attempting to run incremental repair on such should fail-fast and be prevented, with a clear error message.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

CloudStack GSoC 2021 - UX improvements in the UI with Vue.js

Hi there student, this could be interesting task to any UI/UX engineer with some knowledge in Vue.js or relevant tech, it not required huge domain or java knowledge.

Here's some of the main objectives in a brief description:

1. Introduce shortkeys navigation - Being able to navigate without mouse and use just keyboard – for example when on the dashboard when the user presses T, he could be directly transitioned to Templates. Or I for infrastructure, G – global settings.

2. Dialogue confirmations - Confirm dialogues with key – This is not working consistently, some dialogue windows have it some do not. But surely it’ll be great if we can confirm by pressing Enter or Space and cancel by Esc.

3. Forms submission improvements – For example, when deploying instance if you simply click ok without selected network it will prompt you with error and then you’ll need to scroll back to the network place and add it.

More info about the task here: https://github.com/apache/cloudstack/issues/4798

Difficulty: Major

Potential mentors:

Boris Stoyanov, mail: bstoyanov

Script to autogenerate cassandra.yaml

It would be useful to have a script that can ask the user a few questions and generate a recommended cassandra.yaml based on their answers. This will help solve issues like selecting num_tokens. It can also be integrated into OS specific packaging tools such as debconf[1]. Rather than just documenting on the website, it is best to provide a simple script to auto-generate configuration based on common use-cases.

[1] https://wiki.debian.org/debconf

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandracloudstack.apache.org

Global configuration parameter to reject repairs with anti-compaction

We have moved from Cassandra 2.1 to 3.0 and from an operational aspect, the Cassandra repair area changed significantly / got more complex. Beside incremental repairs not working reliably, also full repairs (-full command-line option) are running into anti-compaction code paths, splitting repaired / non-repaired data into separate SSTables, even with full repairs.

Casandra 4.x (with repair enhancements) is quite away for us (for production usage), thus we want to avoid anti-compactions with Cassandra 3.x at any cost. Especially for our on-premise installations at our customer sites, with less control over on how e.g. nodetool is used, we simply want to have a configuration parameter in e.g. cassandra.yaml, which we could use to reject any repair invocations that results in anti-compaction being active.

I know, such a flag still can be flipped then (by the customer), but as a first safety stage possibly sufficient enough to reject anti-compaction repairs, e.g. if someone executes nodetool repair ... the wrong way (accidentally).

Clerezza

Implement a Secure Scuttlebutt Server

Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. The Scuttlebutt Protocol Guide can be found here: https://ssbc.github.io/scuttlebutt-protocol-guide/. Starting from this link https://handbook.scuttlebutt.nz/ you can acquire quite a lot knowledge of the SSB protocol and orientations from the conceptual to the practical aspects of writing and using SSB based applications.

The task of this issue is to implement the functionality of an SSB server as done in JavaScript by https://github.com/ssbc/ssb-server, but using Apache Tuweni (Incubating) for the handshake and an Apache Clerezza based triple store for storing and querying the messages. Apache Tuweni (https://tuweni.apache.org/) is a set of libraries and other tools to aid development of blockchain and other decentralized software in Java and other JVM languages.

For those who are interested in getting more detail about SSB’s features and its operations, see also the paper titled "Secure Scuttlebutt: An Identity-Centric Protocol for Subjective and Decentralized Applications" attached in this issue.

Difficulty: Major

Potential mentors:

Furkan Kamaci, mail: kamaci

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Per-node overrides for table settings

There is a few cases where it's convenient to set some table parameters on only one of a few nodes. For instance, it's useful for experimenting with settings like caching options, compaction, compression, read repair chance, gcGrace ... Another case is when you want to completely migrate to a new setting, but want to do that node-per-node (mainly useful when switching compaction strategy, see CASSANDRA-10898).

I'll note that we can already do some of this through JMX for some of the settings as we have methods like ColumnFamilyStoreMBean.setCompactionParameters(), but:

parameters settings are initially set in CQL. Having to go to JMX for this sounds less consistent to me. The fact we have both a ColumnFamilyStoreMBean.setCompactionParameters() and a ColumnFamilyStoreMBean.setCompactionParametersJson() (as I assume the former one is inconvenient to use) is also proof to me than JMX ain't terribly appropriate.
I think this can be potentially useful for almost all table settings, but we don't expose JMX methods for all settings, and it would be annoying to have to. The method suggested below wouldn't have to be updated every time we add a new settings (if done right).
Changing options through JMX is not persistent across restarts. This may arguably be fine in some cases, but if you're trying to migrate your compaction strategy node per node, or want to experiment with a setting over a mediumish time period, it's mostly a pain.

So what I suggest would be add node overrides in the normal table setting (which would be part of the schema as any other setting). In other words, if you want to set LCS for only one specific node, you'd do:

ALTER TABLE foo WITH node_overrides = { '192.168.0.1' : { 'compaction' : { 'class' : 'LeveledCompactionStrategy' } }
            }

I'll note that I already suggested that idea on CASSANDRA-10898, but as it's more generic than what that latter ticket is about, so creating its own ticket.

Difficulty: Challenging

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Library for Messaging App Storage

Nowadays, more and more companies are using a messaging app to communicate with their customers. The conversations contain not only information about customer engagements and requests, but may reveal interesting facts relevant for product marketing when analysed using business intelligent tools. Thus, having those conversations modelled appropriately is of great importance. RDF is surely one suitable format for modelling and storing those conversations.

The purpose of this task is to define an ontology for conversations and to create a Java library based on Apache Clerezza to store them. Signal (https://signal.org/docs/) is one of many messaging apps which is open source. This task recommends to integrate the library to be developed into Signal (https://github.com/signalapp) for testing.

By resolving this task you will learn

RDF
Apache Clerezza
Signal API

Difficulty: Major

Potential mentors:

Furkan Kamaci, mail: kamaci (at) apache.org

Project Devs, mail:

Cassandra

Add ability to ttl snapshots

It should be possible to add a TTL to snapshots, after which it automatically cleans itself up.

This will be useful together with the auto_snapshot option, where you want to keep an emergency snapshot in case of accidental drop or truncation but automatically remove it after a specified period when it's no longer useful. So in addition to allowing a user to specify a snapshot ttl on nodetool snapshot we should have a auto_snapshot_ttl option that allows a user to set a ttl for automatic snaphots on drop/truncate.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Migrate use of maven-ant-tasks to resolver-ant-tasks

Cassandra resolves dependencies and generates maven pom files through the use of maven-ant-tasks. This is no longer a supported project.

The recommended upgrade is to resolver-ant-tasks. It follows similar APIs so shouldn't be too impactful a change.

The existing maven-ant-tasks has caused some headaches already with internal super poms referencing insecure http:// central maven repository URLs that are no longer supported.

We should also take the opportunity to

define the "test" scope (classpath) for those dependencies only used for tests (currently we are packaging test dependencies into the release binary artefact),
remove the jar files stored in the git repo under the "lib/" folder.

These two above points have to happen in tandem, as the jar files under lib/ are those that get bundled into the build/dist/lib/ and hence the binary artefact. That is, all jar files under lib/ are the project's "compile" scope, and all other dependencies defined in build.xml are either "provided" or "test" scope. These different scopes for dependencies are currently configured in different maven-ant-tasks poms. See https://github.com/apache/cassandra/commit/d43b9ce5092f8879a1a66afebab74d86e9e127fb#r45659668

Expose application_name and application_version in virtual table system_views.clients

Recent java-driver's com.datastax.oss.driver.api.core.session.SessionBuilder respects properties ApplicationName and ApplicationVersion.

It would be helpful to exposed this information via virtual table system_views.clients and with nodetool clientstats.

Difficulty: Normal

Potential mentors:

paulomck, mail: paulo mck (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Add

ability to disable schema changes, repairs, bootstraps, etc (during upgrades)

Plugin Support for CQLSH

Currently the Cassandra drivers offer a plugin authenticator architecture for the support of different authentication methods. This has been leveraged to provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, cqlsh, the included CLI tool, does not offer such support. Switching to a new enhanced authentication scheme thus means being cut off from using cqlsh in normal operation.

We should have a means of using the same plugins and authentication providers as the Python Cassandra driver.

Here's a link to an initial draft of CEP

There are a lot of operations that aren't supposed to be run in a mixed version cluster: schema changes, repairs, topology changes, etc. However, it's easily possible for these operations to be accidentally run by a script, another user unaware of the upgrade, or an operator that's not aware of these rules.

We should make it easy to follow the rules by making it possible to prevent/disable all of these operations through nodetool commands. At the start of an upgrade, an operator can disable all of these until the upgrade has been completed.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Allow table property defaults (e.g. compaction, compression) to be specified for a cluster/keyspace

During an IRC discussion in cassandra-dev it was proposed that we could have table property defaults stored on a Keyspace or globally within the cluster. For example, this would allow users to specify "All new tables on this cluster should default to LCS with SSTable size of 320MiB" or "all new tables in Keyspace XYZ should have Zstd commpression with a 8 KiB block size" or "default_time_to_live should default to 3 days" etc ... This way operators can choose the default that makes sense for their organization once (e.g. LCS if they are running on fast SSDs), rather than requiring developers creating the Keyspaces/Tables to make the decision on every creation (often without context of which choices are right).

A few implementation options were discussed including:

A YAML option
Schema provided at the Keyspace level that would be inherited by any tables automatically
Schema provided at the Cluster level that would be inherited by any Keyspaces or Tables automatically

In IRC it appears that rough consensus was found in having global -> keyspace -> table defaults which would be stored in schema (no YAML configuration since this isn't node level really, it's a cluster level config).

Difficulty: Challenging

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Prevent and fail-fast any attempts to incremental repair cdc/mv tables

Running incremental repairs on CDC or MV tables breaks them.

Attempting to run incremental repair on such should fail-fast and be prevented, with a clear error message.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Script to autogenerate cassandra.yaml

It would be useful to have a script that can ask the user a few questions and generate a recommended cassandra.yaml based on their answers. This will help solve issues like selecting num_tokens. It can also be integrated into OS specific packaging tools such as debconf[1]. Rather than just documenting on the website, it is best to provide a simple script to auto-generate configuration based on common use-cases.

[1] https://wiki.debian.org/debconf

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Global configuration parameter to reject repairs with anti-compaction

We have moved from Cassandra 2.1 to 3.0 and from an operational aspect, the Cassandra repair area changed significantly / got more complex. Beside incremental repairs not working reliably, also full repairs (-full command-line option) are running into anti-compaction code paths, splitting repaired / non-repaired data into separate SSTables, even with full repairs.

Casandra 4.x (with repair enhancements) is quite away for us (for production usage), thus we want to avoid anti-compactions with Cassandra 3.x at any cost. Especially for our on-premise installations at our customer sites, with less control over on how e.g. nodetool is used, we simply want to have a configuration parameter in e.g. cassandra.yaml, which we could use to reject any repair invocations that results in anti-compaction being active.

I know, such a flag still can be flipped then (by the customer), but as a first safety stage possibly sufficient enough to reject anti-compaction repairs, e.g. if someone executes nodetool repair ... the wrong way (accidentally).

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Per-node overrides for table settings

There is a few cases where it's convenient to set some table parameters on only one of a few nodes. For instance, it's useful for experimenting with settings like caching options, compaction, compression, read repair chance, gcGrace ... Another case is when you want to completely migrate to a new setting, but want to do that node-per-node (mainly useful when switching compaction strategy, see CASSANDRA-10898).

I'll note that we can already do some of this through JMX for some of the settings as we have methods like ColumnFamilyStoreMBean.setCompactionParameters(), but:

parameters settings are initially set in CQL. Having to go to JMX for this sounds less consistent to me. The fact we have both a ColumnFamilyStoreMBean.setCompactionParameters() and a ColumnFamilyStoreMBean.setCompactionParametersJson() (as I assume the former one is inconvenient to use) is also proof to me than JMX ain't terribly appropriate.
I think this can be potentially useful for almost all table settings, but we don't expose JMX methods for all settings, and it would be annoying to have to. The method suggested below wouldn't have to be updated every time we add a new settings (if done right).
Changing options through JMX is not persistent across restarts. This may arguably be fine in some cases, but if you're trying to migrate your compaction strategy node per node, or want to experiment with a setting over a mediumish time period, it's mostly a pain.

So what I suggest would be add node overrides in the normal table setting (which would be part of the schema as any other setting). In other words, if you want to set LCS for only one specific node, you'd do:

ALTER TABLE foo WITH node_overrides = { '192.168.0.1' : { 'compaction' : { 'class' : 'LeveledCompactionStrategy' } }

Add nodetool command to display or export the contents of a virtual table

Several virtual tables were recently added, but they're currently only accessible via cqlsh or programmatically. While this is valuable for many use cases, operators are accustomed with the convenience of querying system metrics with a simple nodetool command.

In addition to that, a relatively common request is to provide nodetool output in different formats (JSON, YAML and even XML) (~~CASSANDRA-5977~~, ~~CASSANDRA-12035~~, ~~CASSANDRA-12486~~, CASSANDRA-12698, CASSANDRA-12503). However this requires lots of manual labor as each nodetool subcommand needs to be adapted to support new output formats.

I propose adding a new nodetool command that will consistently print to the standard output the contents of a virtual table. By default the command will print the output in a human-readable tabular format similar to cqlsh, but a "--format" parameter can be specified to modify the output to some other format like JSON or YAML.

It should be possible to add a limit to the amount of rows displayed and filter to display only rows from a specific keyspace or table. The command should be flexible and provide simple hooks for registration and customization of new virtual tables.

I propose calling this command nodetool show <virtualtable> (naming bikeshedding welcome), for example:

nodetool show --list
            caches
            clients
            internode_inbound
            internode_outbound
            settings
            sstable_tasks
            system_properties
            thread_pools
            
            nodetool}
 show clients --format yaml
            ...
            nodetool show internode_outboud --format json
            ...
            nodetool show sstabletasks --keyspace my_ks --table -my_table
            ...

I'll note that I already suggested that idea on CASSANDRA-10898, but as it's more generic than what that latter ticket is about, so creating its own ticket.

Difficulty: Challenging

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Expose application_name and application_version in virtual table system_views.clients

Recent java-driver's com.datastax.oss.driver.api.core.session.SessionBuilder respects properties ApplicationName and ApplicationVersion.

It would be helpful to exposed this information via virtual table system_views.clients and with nodetool clientstats.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Add ability to disable schema changes, repairs, bootstraps, etc (during upgrades)

There are a lot of operations that aren't supposed to be run in a mixed version cluster: schema changes, repairs, topology changes, etc. However, it's easily possible for these operations to be accidentally run by a script, another user unaware of the upgrade, or an operator that's not aware of these rules.

We should make it easy to follow the rules by making it possible to prevent/disable all of these operations through nodetool commands. At the start of an upgrade, an operator can disable all of these until the upgrade has been completed.

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Allow table property defaults (e.g. compaction, compression) to be specified for a cluster/keyspace

During an IRC discussion in cassandra-dev it was proposed that we could have table property defaults stored on a Keyspace or globally within the cluster. For example, this would allow users to specify "All new tables on this cluster should default to LCS with SSTable size of 320MiB" or "all new tables in Keyspace XYZ should have Zstd commpression with a 8 KiB block size" or "default_time_to_live should default to 3 days" etc ... This way operators can choose the default that makes sense for their organization once (e.g. LCS if they are running on fast SSDs), rather than requiring developers creating the Keyspaces/Tables to make the decision on every creation (often without context of which choices are right).

A few implementation options were discussed including:

A YAML option
Schema provided at the Keyspace level that would be inherited by any tables automatically
Schema provided at the Cluster level that would be inherited by any Keyspaces or Tables automatically

In IRC it appears that rough consensus was found in having global -> keyspace -> table defaults which would be stored in schema (no YAML configuration since this isn't node level really, it's a cluster level config).

Difficulty: Challenging

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Add nodetool command to display or export the contents of a virtual table

Several virtual tables were recently added, but they're currently only accessible via cqlsh or programmatically. While this is valuable for many use cases, operators are accustomed with the convenience of querying system metrics with a simple nodetool command.

In addition to that, a relatively common request is to provide nodetool output in different formats (JSON, YAML and even XML) (~~CASSANDRA-5977~~, ~~CASSANDRA-12035~~, ~~CASSANDRA-12486~~, CASSANDRA-12698, CASSANDRA-12503). However this requires lots of manual labor as each nodetool subcommand needs to be adapted to support new output formats.

I propose adding a new nodetool command that will consistently print to the standard output the contents of a virtual table. By default the command will print the output in a human-readable tabular format similar to cqlsh, but a "--format" parameter can be specified to modify the output to some other format like JSON or YAML.

It should be possible to add a limit to the amount of rows displayed and filter to display only rows from a specific keyspace or table. The command should be flexible and provide simple hooks for registration and customization of new virtual tables.

I propose calling this command nodetool show <virtualtable> (naming bikeshedding welcome), for example:

nodetool show --list
            caches
            clients
            internode_inbound
            internode_outbound
            settings
            sstable_tasks
            system_properties
            thread_pools
            
            nodetool show clients --format yaml
            ...
            nodetool show internode_outboud --format json
            ...
            nodetool show sstabletasks --keyspace my_ks --table -my_table
            ...

Difficulty: Normal

Potential mentors:

paulo, mail: paulo (at) apache.org

Project Devs, mail: dev (at) cassandra.apache.org

Beam

Profile and improve performance for the local FnApiRunner

The FnApiRunner is undergoing a series of changes to support streaming. These changes are altering its execution significantly, and may introduce inefficiencies.

This project has the following deliverables:

A report with results from profiling the execution of a pipeline, and finding hotspots, and inefficiencies
Code improvements to speed up the execution of the FnApiRunner
Improvements to the FnApiRunner manual to instruct others on how to do profiling.

Tools that you may need to use:

Benchmarks for the Python direct runner in http://metrics.beam.apache.org
The FnApiRunner and TestStream microbenchmarks in sdks/python/apache_beam/tools/
A profiling tool like: https://pypi.org/project/flameprof/ or https://github.com/uber-archive/pyflame
Google Docs

Contact Pablo in dev@beam.apache.org^{Image Added} to ask questions about this project.

Difficulty: P2

Potential mentors:

Pablo Estrada, mail: pabloem (at) apache.org

Project Devs, mail: dev (at) beam.apache.org

Apache NuttX

QA for NuttX with tests using QEMU, Renode and/or real hardware

Currently NuttX supports more than 150 embedded boards and sometime some Pull Requests end up generating issues on some of these boards because the patch author is not able to test on all boards.

So to solve this issue we need to create some automatic board test (could be using QEMU, Renode or real hardware). This QA solution should be integrated on our current CI to automatically test each new submitted PR.

Difficulty: Normal

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

NuttX Support for Rapid Control Applications Development with pysimCoder

The main goal is integrating pysimCoder with NuttX to develop NuttX applications easily and faster for Engineering Students!

The pysimCoder is open-source Rapid (Control) Application Development Tool (RAD) which targets broad range of operating systems and target platforms. It has a graphical editor, which is able to translate a block diagram into C code. The C-code can be easily integrated into a main file for different embedded and linux systems. The design of the controller is performed using a Python script.

The NuttX is ideal real-time operating systems to combine with pysimCoder to prepare Rapid Control Prototyping (RCP) platforms based on small and mid-range embedded microcontrollers systems. NuttX POSIX standard programing model allows fast porting of applications and pysimCoder support between GNU/Linux for large designs to cheaper and smaller MCU based systems for faster and simpler applications which gives great potential to fill large gaps between hobby grade solutions supported by Arduino or microPython and professional systems requiring expensive software licenses (even for hobby grade hardware) and for professional use even expensive platforms.

The pysimCoder project repository is hosted here:

http://robertobucher.dti.supsi.ch/python/pysimcoder/

As the demonstration platform and BSP enhanced to support more sensors and actuators the studend should use for example the iMX RT1050 that has support to CAN-FD.

Other boards like the STM32F4Discovery and ESP32/ESP32-C3 could be used, but these boards don't have CAN-FD support.

Difficulty: Normal

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

NuttX NAND Flash Subsystem

Currently NuttX has support only for NOR Flash and eMMC as solid state storage.

Although for low-end embedded systems NOR Flash still much used, for some devices that need bigger storage, NAND Flash is a better option, because its price per MB is very low.

In the other NAND Flash brings many challenges: you need to map and track all the bad-blocks, you need to have a good filesystem for wear leveling. Currently the SmartFS and LittleFS offer some kind wear leveling for NOR Flash. It needs to be adapted to NAND Flash.

Difficulty: Major

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

Device Tree support for NuttX

Device Tree will simplify the way as boards are configured to support NuttX. Currently for each board the developer/user need to manually create an initialization file for each feature or device (expect when the device is already in the common board folder).

Matias Nitsche (aka v0id) create a very descriptive and information explanation here: https://github.com/apache/incubator-nuttx/issues/1020

The goal for this project is to add Device Tree support for NuttX and let it to be configurable (low end board should be able to avoid using Device Tree for instance).

Difficulty: Major

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

Rust integration on NuttX

The Rust language is gain some momentum as an alternative to C and C++ for embedded system (https://www.rust-lang.org/what/embedded) and it should be very useful to be able to develop NuttX applications using Rust language.

Sometime Yoshiro Sugino already ported the Rust standard libraries, but it was not a complete port and wasn't integrated on NuttX. Anyway this initial port could be used as starting point for some student willing to add official support on NuttX.

Difficulty: Normal

(More details to be added)

Difficulty: Major

Potential mentors:

Raymond Xu, mail: xushiyan (at) apache.org

Project Devs, mail: dev (at) hudi.apache.org

[UMBRELLA] Support Apache Calcite for writing/querying Hudi datasets

(More details to be added)

Difficulty: Major

Potential mentors:

Raymond Xu, mail: xushiyan

This project has the following deliverables:

A report with results from profiling the execution of a pipeline, and finding hotspots, and inefficiencies
Code improvements to speed up the execution of the FnApiRunner
Improvements to the FnApiRunner manual to instruct others on how to do profiling.

Tools that you may need to use:

Benchmarks for the Python direct runner in http://metrics.beam.apache.org
The FnApiRunner and TestStream microbenchmarks in sdks/python/apache_beam/tools/
A profiling tool like: https://pypi.org/project/flameprof/ or https://github.com/uber-archive/pyflame
Google Docs

Contact Pablo in dev@beam.apache.org^{Image Removed} to ask questions about this project.

Difficulty: P2

Potential mentors:

Pablo Estrada, mail: pabloem (at) apache.org

Project Devs, mail: dev (at) beamhudi.apache.org

Apache NuttX

[UMBRELLA] Support Apache Beam for incremental tailing

(More details to be added)

Difficulty: Major

QA for NuttX with tests using QEMU, Renode and/or real hardware

Currently NuttX supports more than 150 embedded boards and sometime some Pull Requests end up generating issues on some of these boards because the patch author is not able to test on all boards.

So to solve this issue we need to create some automatic board test (could be using QEMU, Renode or real hardware). This QA solution should be integrated on our current CI to automatically test each new submitted PR.

Difficulty: Normal

Potential mentors:

Alan Carvalho de AssisVinoth Chandar, mail: acassis vinoth (at) apache.org

Project Devs, mail: dev (at) nuttxhudi.apache.org

NuttX Support for Rapid Control Applications Development with pysimCoder

Apache Fineract

Fineract Credit Bureau Integration Phase 4

Mentors

Nikhil Pawar
Rahul Pawar
Nayan Ambali, Ed Cable
Overview & Objectives
Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client. Apache Fineract can be integrated with a popular CBs in India and from other regions (based on the demand).

Description

Building off the work that was kicked off in 2016, during the 2020 Google Summer of Code, Rahul Pawar, completed the credit bureau integration module with integrations for the credit bureau in Myanmar, MCIX. This project will continue extending the functionality of the module and work on integrations with the major credit bureaus in Latin America and Sub-Saharan Africa.

The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client.

Helpful Skills

SQL, Java, Javascript, Git, Web Services, Big Data (Hadoop, Hive)

Impact

The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs.

Other Resources

Documentation: https://cwiki.apache.org/confluence/display/FINERACT/Documentation+to+use+Integrated+Credit+Bureau
For the scope of this project , see https://jira.apache.org/jira/browse/FINERACT-734

Detailed requirements: https://goo.gl/aZWMZa

Source Code: https://github.com/apache/fineract/pulls?q=is%3Apr+is%3Aclosed+credit+bureau

The main goal is integrating pysimCoder with NuttX to develop NuttX applications easily and faster for Engineering Students!

The pysimCoder is open-source Rapid (Control) Application Development Tool (RAD) which targets broad range of operating systems and target platforms. It has a graphical editor, which is able to translate a block diagram into C code. The C-code can be easily integrated into a main file for different embedded and linux systems. The design of the controller is performed using a Python script.

The NuttX is ideal real-time operating systems to combine with pysimCoder to prepare Rapid Control Prototyping (RCP) platforms based on small and mid-range embedded microcontrollers systems. NuttX POSIX standard programing model allows fast porting of applications and pysimCoder support between GNU/Linux for large designs to cheaper and smaller MCU based systems for faster and simpler applications which gives great potential to fill large gaps between hobby grade solutions supported by Arduino or microPython and professional systems requiring expensive software licenses (even for hobby grade hardware) and for professional use even expensive platforms.

The pysimCoder project repository is hosted here:

http://robertobucher.dti.supsi.ch/python/pysimcoder/

As the demonstration platform and BSP enhanced to support more sensors and actuators the studend should use for example the iMX RT1050 that has support to CAN-FD.

Other boards like the STM32F4Discovery and ESP32/ESP32-C3 could be used, but these boards don't have CAN-FD support.

Difficulty: Normal

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

NuttX NAND Flash Subsystem

Currently NuttX has support only for NOR Flash and eMMC as solid state storage.

Although for low-end embedded systems NOR Flash still much used, for some devices that need bigger storage, NAND Flash is a better option, because its price per MB is very low.

In the other NAND Flash brings many challenges: you need to map and track all the bad-blocks, you need to have a good filesystem for wear leveling. Currently the SmartFS and LittleFS offer some kind wear leveling for NOR Flash. It needs to be adapted to NAND Flash.

Difficulty: Major

Potential mentors:

Alan Carvalho de AssisEd Cable, mail: acassis edcable (at) apache.org

Project Devs, mail: dev (at) nuttxfineract.apache.org

Device Tree support for NuttX

Update Fineract 1.x Android Client SDK

Mentors

Chinmay Kulkarni
Overview & Objectives
The goal of this project is to continue work on developing the Fineract 1.x Client Android SDK which will be used in other Mifos Mobile Applications (android-client, mifos-mobile, mobile-wallet). The project aims to remove a lot of repeated code in the mobile apps and help mobile apps easily migrate to newer versions of Apache Fineract 1.x
Description
The student will be working on implementing the following things:

Generate and release latest Fineract Client SDK for Android using the Open API Specification of Apache Fineract
Generate and publish documentation for the Fineract Android Client SDK
Add support for RxJava + LiveData
Migrate Mifos Android Field Officer App project to consume the new Fineract Client Android SDK
Provide testing coverage throughout the SDK
Implement CI/CD to automate steps 1 and 2
Helpful Skills
Java, Kotlin, Android, Swagger Specification, Open API Specification, Spring (Good to have)
Impact
Enabling other mifos mobile apps to easily migrate to latest versions of Fineract.
More stable and error free codebase
Other Resources
Last year progress - https://gist.github.com/Grandolf49/f79537436a467dac0baa9458a38290c5
Jira Issue for reference: https://issues.apache.org/jira/browse/FINERACT-838
https://github.com/apache/fineract
https://github.com/openMF/fineract-client

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable

Device Tree will simplify the way as boards are configured to support NuttX. Currently for each board the developer/user need to manually create an initialization file for each feature or device (expect when the device is already in the common board folder).

Matias Nitsche (aka v0id) create a very descriptive and information explanation here: https://github.com/apache/incubator-nuttx/issues/1020

The goal for this project is to add Device Tree support for NuttX and let it to be configurable (low end board should be able to avoid using Device Tree for instance).

Difficulty: Major

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

Rust integration on NuttX

The Rust language is gain some momentum as an alternative to C and C++ for embedded system (https://www.rust-lang.org/what/embedded) and it should be very useful to be able to develop NuttX applications using Rust language.

Sometime Yoshiro Sugino already ported the Rust standard libraries, but it was not a complete port and wasn't integrated on NuttX. Anyway this initial port could be used as starting point for some student willing to add official support on NuttX.

Difficulty: Normal

Potential mentors:

Alan Carvalho de Assis, mail: acassis (at) apache.org

Project Devs, mail: dev (at) nuttx.apache.org

Apache Hudi

fineract.apache.org

Live Fineract CN API Documentation (Swagger, etc.)

Mentors

Sanyam Goel
Manthan Surkar
Overview & Objectives
The aim of this project is to provide a visual display of the Fineract CN API Documentation. We are now starting to use more of the Postman toolset for our developer portal and this project would focus on extending the existing work that was done.

Description

This project involves providing a visual display of the API Documentation of Apache Fineract CN. Student would have to optimize documentation snippets ( .adoc ), document any service which isn't completely documented like template and reporting, document failing unit tests too and develop a visual website where these html files will be hosted.

Helpful Skills

Java, PostgreSQL, MariaDB, Cassandra, TDD With JUnit 4, Spring REST Docs, Asciidoctor, HTML/CSS, Graphic Design

Impact

A visual presentation of the Fineract CN APIs will be a key building block for an enabling environment for developers working on Fineract CN.

Other Resources

Snowflake integration w/ Apache Hudi

Difficulty: Major

Potential mentors:

sivabalan narayanan, mail: shivnarayan (at) apache.org

Project Devs, mail: dev (at) hudi.apache.org

Apache Airflow integration w/ Apache Hudi

Difficulty: Major

Potential mentors:

sivabalan narayanan, mail: shivnarayan (at) apache.org

Project Devs, mail: dev (at) hudi.apache.org

Fineract Credit Bureau Integration Phase 4

Mentors

Nikhil Pawar
Rahul Pawar
Nayan Ambali, Ed Cable
Overview & Objectives
Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client. Apache Fineract can be integrated with a popular CBs in India and from other regions (based on the demand).

Description

Building off the work that was kicked off in 2016, during the 2020 Google Summer of Code, Rahul Pawar, completed the credit bureau integration module with integrations for the credit bureau in Myanmar, MCIX. This project will continue extending the functionality of the module and work on integrations with the major credit bureaus in Latin America and Sub-Saharan Africa.

The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client.

Helpful Skills

SQL, Java, Javascript, Git, Web Services, Big Data (Hadoop, Hive)

Impact

The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs.

Other Resources

Documentation: https://cwiki.apache.org/confluence/display/FINERACT/Documentation+to+use+Integrated+Credit+Bureau
For the scope of this project , see https://jira.apache.org/jira/browse/FINERACT-734

Detailed requirements: https://goo.gl/aZWMZa

Source Code: https://github.com/apache/fineract/pulls?q=is%3Apr+is%3Aclosed+credit+bureau

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Update Fineract 1.x Android Client SDK

Mentors

Chinmay Kulkarni
Overview & Objectives
The goal of this project is to continue work on developing the Fineract 1.x Client Android SDK which will be used in other Mifos Mobile Applications (android-client, mifos-mobile, mobile-wallet). The project aims to remove a lot of repeated code in the mobile apps and help mobile apps easily migrate to newer versions of Apache Fineract 1.x
Description
The student will be working on implementing the following things:

Generate and release latest Fineract Client SDK for Android using the Open API Specification of Apache Fineract
Generate and publish documentation for the Fineract Android Client SDK
Add support for RxJava + LiveData
Migrate Mifos Android Field Officer App project to consume the new Fineract Client Android SDK
Provide testing coverage throughout the SDK
Implement CI/CD to automate steps 1 and 2
Helpful Skills
Java, Kotlin, Android, Swagger Specification, Open API Specification, Spring (Good to have)
Impact
Enabling other mifos mobile apps to easily migrate to latest versions of Fineract.
More stable and error free codebase
Other Resources
Last year progress - https://gist.github.com/Grandolf49/f79537436a467dac0baa9458a38290c5
Jira Issue for reference: https://issues.apache.org/jira/browse/FINERACT-838
https://github.com/apache/fineract
https://github.com/openMF/fineract-client

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Live Fineract CN API Documentation (Swagger, etc.)

Mentors

Sanyam Goel
Manthan Surkar
Overview & Objectives
The aim of this project is to provide a visual display of the Fineract CN API Documentation. We are now starting to use more of the Postman toolset for our developer portal and this project would focus on extending the existing work that was done.

Description

This project involves providing a visual display of the API Documentation of Apache Fineract CN. Student would have to optimize documentation snippets ( .adoc ), document any service which isn't completely documented like template and reporting, document failing unit tests too and develop a visual website where these html files will be hosted.

Helpful Skills

Java, PostgreSQL, MariaDB, Cassandra, TDD With JUnit 4, Spring REST Docs, Asciidoctor, HTML/CSS, Graphic Design

Impact

A visual presentation of the Fineract CN APIs will be a key building block for an enabling environment for developers working on Fineract CN.

Other Resources

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

fineract.apache.org

Create Open Banking Layer for Fineract 1.x Self-Service Apps

Mentors

Avik Ganguly
Naman Dwivedi

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America.

Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs.

The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

Description

The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API.

For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway.

For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway.

For example:

Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#loans_create
Used by Fineract 1.x Self-Service App
ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#client_images
Used by Mifos Mobile and Mobile Wallet
Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI)
https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1
Sample APIs to be Documented
-------------------------------------------
Fineract 1.x Self Service App (Mifos Mobile) API Matrix (completed by Ashwin)
https://docs.google.com/spreadsheets/d/1gR84jZzLF-mM0iRw5JyeMAsHMK6RQPK0vyDmNAY9VhE/edit#gid=0
Fineract 1.x Self-Service App (Mifos Mobile) API Matrix (completed by Shivangi)
https://docs.google.com/spreadsheets/d/1exTv68v1IW_ygS7mSj0_ySFWGTj06NcxPZeNLjNIy6Y/edit?pli=1#gid=0

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2

Impact

By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers.

Other Resources

CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion
Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis
Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth

https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2
Open Banking Adapter: https://github.com/openMF/openbanking-adapter
Transforms Open Banking API to Fineract API
Works with both Fineract 1.x and Fineract CN
Can connect to different API gateways and can transform against different API standards.

Reference Open Banking Fintech App:

Backend: https://github.com/openMF/openbanking-tpp-server
GUI: https://github.com/openMF/openbanking-tpp-client
Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

See https://openmf.github.io/mobileapps.github.io/

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Create Open Banking Layer for Mobile Wallet Apps

Mentors

Avik Ganguly
Devansh Aggarwal

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America.

Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs.

The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

Description

The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API.

For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway.

For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway.

For example:

Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#loans_create
Used by Fineract 1.x Self-Service App
ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#client_images
Used by Mifos Mobile and Mobile Wallet
Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI)
https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1
Sample APIs to be Documented
-------------------------------------------

Mobile Wallet API Matrix (completed by Devansh)
https://docs.google.com/spreadsheets/d/1VgpIwN2JsljWWytk_Qb49kKzmWvwh6xa1oRgMNIAv3g/edit#gid=0

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2

Impact

By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers.

Other Resources

CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion
Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis
Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth

https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2
Open Banking Adapter: https://github.com/openMF/openbanking-adapter
Transforms Open Banking API to Fineract API
Works with both Fineract 1.x and Fineract CN
Can connect to different API gateways and can transform against different API standards.

Reference Open Banking Fintech App:

Backend: https://github.com/openMF/openbanking-tpp-server
GUI: https://github.com/openMF/openbanking-tpp-client
Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

See https://openmf.github.io/mobileapps.github.io/

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Reference Open Banking Fintech App on Fineract

Mentors

Ahmad Jawid Muhammadi
Naman Dwivedi
Shivansh Tiwari

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API

To demonstrate these Open Banking APIs and use cases that third parties and fintechs can provide we have developed a cross-platform reference mobile app on Kotlin to showcase a number of these features. It currently connects with the Open Bank Project that adheres to the UK Open Banking API standard. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

The breadth and variety of apps that could be built leveraging these APIs from region to region is endless. We would like this app to be built in an extensible and modular fashion such that core libraries and components could be re-used across different use cases with this framework as the foundation and multiple reference apps on top. Applications include personal financial management apps aggregating information from multiple bank accounts in one place, wallet apps allowing payments to be made from different banks, lending apps, leveraging data and insight from multiple accounts, savings apps, etc.

Description

Intern would work on refining the initial architecture of the framework, the UI and user experience, core use cases including customer authentication and onboarding that was implemented in 2020 and integrating with the Fineract Open Banking APIs and Mojaloop PISP APIs to demonstrate use cases around account information request and payment initiation.

Aggregating account information across multiple banks/financial institution
Initiating payments across multiple financial institutions
Integrate with additional Fineract Open Banking APIs
Integrate with Mojaloop PISP APIs.

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin

Impact

By providing an extensible open banking fintech app framework, allow partners a complete stack of Open Banking APIs and reference front-end application to rapidly build innovation via Open Banking APIs.

Other Resources

2020 Progress: https://gist.github.com/ankurs287/4ef7c3de462073bf36bd5247479cb176

Create Open Banking Layer for Fineract 1.x Self-Service Apps

Mentors

Avik Ganguly
Naman Dwivedi

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America.

Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs.

The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

Description

The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API.

For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway.

For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway.

For example:

Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#loans_create
Used by Fineract 1.x Self-Service App
ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#client_images
Used by Mifos Mobile and Mobile Wallet
Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI)
https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1
Sample APIs to be Documented
-------------------------------------------
Fineract 1.x Self Service App (Mifos Mobile) API Matrix (completed by Ashwin)
https://docs.google.com/spreadsheets/d/1gR84jZzLF-mM0iRw5JyeMAsHMK6RQPK0vyDmNAY9VhE/edit#gid=0
Fineract 1.x Self-Service App (Mifos Mobile) API Matrix (completed by Shivangi)
https://docs.google.com/spreadsheets/d/1exTv68v1IW_ygS7mSj0_ySFWGTj06NcxPZeNLjNIy6Y/edit?pli=1#gid=0

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2

Impact

By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers.

Other Resources

CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion
Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis
Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth

https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2
Open Banking Adapter: https://github.com/openMF/openbanking-adapter
Transforms Open Banking API to Fineract API
Works with both Fineract 1.x and Fineract CN
Can connect to different API gateways and can transform against different API standards.

Reference Open Banking Fintech App:

Backend: https://github.com/openMF/openbanking-tpp-server

GUI: https://github.com/openMF/openbanking-tpp-client

Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI

-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

See https://openmf.github.io/mobileapps.github.io/

-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Improve Robustness of Mifos X and Apache Fineract by Fixing Issues/Feature Requests in Backlog

Difficulty: Major

Potential mentors:

Ed Cable, mail: edcable (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

Create Open Banking Layer for Mobile Wallet Apps

Mentors

Avik Ganguly
Devansh Aggarwal

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America.

Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs.

The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

Description

The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API.

For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway.

For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway.

For example:

Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#loans_create
Used by Fineract 1.x Self-Service App
ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI)
https://demo.mifos.io/api-docs/apiLive.htm#client_images
Used by Mifos Mobile and Mobile Wallet
Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI)
https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1
Sample APIs to be Documented
-------------------------------------------

Mobile Wallet API Matrix (completed by Devansh)
https://docs.google.com/spreadsheets/d/1VgpIwN2JsljWWytk_Qb49kKzmWvwh6xa1oRgMNIAv3g/edit#gid=0

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2

Impact

By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers.

Other Resources

CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion
Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis
Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth

Overview & Objectives
Mifos X and Apache Fineract is widely used by financial institutions of all different sizes and methodologies around the world. With that widespread user base there is a vast array of different processes and procedures that would like to be supported as slight modifications over the common functionality provided. Over the past several years, we have captured these minor enhancements in our issue tracker as feature requests. Also included in this backlog or additional minor and less critical bugs that have been reported but have not been fixed yet. This backlog has grown and it would be a very impactful project for an intern to work on completing as many of these bug fixes and minor enhancement as possible.
The difficult level of these issues ranges from low to higher and touch all componets of the platform - most don't require too much domain knowledge but some will.

Description
We have groomed the backlog and tagged issues and feature requests that are relevant for this project with the labels gsoc and/or Volunteer. Priority level of tasks is measured by p1 being the highest priority. Tasks with an assigned fix version of either 1.4.0 or 1.5.0 have a higher priority.
There are more than 120 tickets in the saved filter. You are not expected to complete all of the tasks in the backlog but throughout the internship you should fix as many issues/feature requests as possible. You will work with your mentor to deliver a plan for each sprint and adjust velocity as you get scaled up.
Issues to be worked on can be found under the blocked issue list below

Helpful Skills:
HTML, Spring, Hibernate, REST, Java, AngularJS, Javascript, SQL

Impact:
Better internal control and financial transparency

Other Resources:
Getting Started with Apache Fineract:

https://cwiki.apache.org/confluence/display/FINERACT/

Customer

Getting+

Self-Service+Phase+2
Open Banking Adapter: https://github.com/openMF/openbanking-adapter

Transforms Open Banking API to Fineract API

Works with both Fineract 1.x and Fineract CN

Can connect to different API gateways and can transform against different API standards.

Reference Open Banking Fintech App:

Backend: https://github.com/openMF/openbanking-tpp-server
GUI: https://github.com/openMF/openbanking-tpp-client
Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

Started+Docs

Difficulty: Major

Potential mentors:

Sanyam Goel, mail: sanyam96 (at) apache.org

Project Devs, mail: dev (at) fineract.apache.org

APISIX

Apache APISIX: supports obtaining etcd data information through plugin

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

When we get the stored data of etcd, we need to manually execute the URI request method to get each piece of data, and we cannot monitor the changed data in etcd. This is not friendly to issues such as obtaining multiple etcd stored data and monitoring etcd data changes. Therefore, we need to design a method to solve this problem.

Task

In the Apache APISIX (https://github.com/apache/apisix) project, implement a plug-in with the following functions:

1.Find route based on URI;
2.Watch etcd to print out the object that has recently changed；
3.Query the corresponding data based on ID (route, service, consumer, etc.).

Relevant Skills

1. Master Lua language;
2. Have a basic understanding of API Gateway or Web server;
3. Be familiar with ETCD.

Mentor

Yuelin Zheng, yuelinz99@gmail.comSee https://openmf.github.io/mobileapps.github.io/

Difficulty: Major

Potential mentors:

Ed CableYuelin Zheng, mail: edcable firstsawyou (at) apache.org

Project Devs, mail: dev (at) fineractapisix.apache.org

Apache APISIX: enhanced authentication for Dashboard

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

At present, Apache APISIX Dashboard only supports simple username and password login, we need a universal authentication mechanism that can connect to user's existing identity provider.

Task

In the Apache APISIX dashboard (https://github.com/apache/apisix-dashboard) project
1. Implement a universal login class
2. Support LDAP connection
3. Support OAuth2 connection

Relevant Skills
1. Golang
2. TypeScript
3. Be familiar with ETCD

Mentor
Junxu Chen, PMC of Apache APISIX, chenjunxu@apache.org

Difficulty: Major

Potential mentors:

Junxu Chen, mail: chenjunxu (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Apache APISIX: support to fetch more useful information of client request

What's Apache APISIX?

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background (route matching and run plugins)

When the client completes a request, there is a lot of useful information inside Apache APISIX.

Image Added

Task

Needs a way to show it. It is convenient for callers to troubleshoot problems and understand the workflow of Apache APISIX.

The first version target can display:
1. Which route is matched.
2. Which plugins are loaded.

In subsequent versions, we will add more information that the caller cares about, such as:

Whether the global plugin is executed
Time consumption statistics
The return value when the plugin is executed
Relevant Skills

1. Master Lua language
2. Have a basic understanding of API Gateway or Web server

Reference Open Banking Fintech App on Fineract

Mentors

Ahmad Jawid Muhammadi
Naman Dwivedi
Shivansh Tiwari

Overview & Objectives

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API

To demonstrate these Open Banking APIs and use cases that third parties and fintechs can provide we have developed a cross-platform reference mobile app on Kotlin to showcase a number of these features. It currently connects with the Open Bank Project that adheres to the UK Open Banking API standard. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

The breadth and variety of apps that could be built leveraging these APIs from region to region is endless. We would like this app to be built in an extensible and modular fashion such that core libraries and components could be re-used across different use cases with this framework as the foundation and multiple reference apps on top. Applications include personal financial management apps aggregating information from multiple bank accounts in one place, wallet apps allowing payments to be made from different banks, lending apps, leveraging data and insight from multiple accounts, savings apps, etc.

Description

Intern would work on refining the initial architecture of the framework, the UI and user experience, core use cases including customer authentication and onboarding that was implemented in 2020 and integrating with the Fineract Open Banking APIs and Mojaloop PISP APIs to demonstrate use cases around account information request and payment initiation.

Aggregating account information across multiple banks/financial institution
Initiating payments across multiple financial institutions
Integrate with additional Fineract Open Banking APIs
Integrate with Mojaloop PISP APIs.

Helpful Skills

Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin

Impact

By providing an extensible open banking fintech app framework, allow partners a complete stack of Open Banking APIs and reference front-end application to rapidly build innovation via Open Banking APIs.

Other Resources

2020 Progress: https://gist.github.com/ankurs287/4ef7c3de462073bf36bd5247479cb176

Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

Difficulty: Major

Potential mentors:

Ed CableYuanSheng Wang, mail: edcable membphis (at) apache.org

Project Devs, mail: dev (at) fineractapisix.apache.org

...

Apache APISIX:

supports obtaining etcd data information through plugin

support apply certificates from Let’s Encrypt or any other ACMEv2 service

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

When we get the stored data of etcd, we need to manually execute the URI request method to get each piece of data, and we cannot monitor the changed data in etcd. This is not friendly to issues such as obtaining multiple etcd stored data and monitoring etcd data changes. Therefore, we need to design a method to solve this problem.

The data plane of Apache APISIX supports dynamic loading of ssl certificates, but the control plane does not have the support of ACME.
Although users can use other tools to obtain ACME certificates, and then call the admin API to write them into Apache APISIX, this is not convenient for many users.

Task

In the Apache APISIX dashboard (https://github.com/apache/apisix-dashboard) project, implement a plug-in with the following functions:

1.Find route based on URI;
2.Watch etcd to print out the object that has recently changed；
3.Query the corresponding data based on ID (route, service, consumer, etc.).

Relevant Skills

1. Master Lua language;
2. Have a basic understanding of API Gateway or Web server;
3. Be familiar with ETCD.

Mentor

add support for ACME, which can automatically obtain and update certificates

Relevant Skills
TypeScript
Golang
familiar with Apache APISIX's admin API

Mentor
Ming Wen, PMC of Apache APISIX, wenming@apache.orgYuelin Zheng, yuelinz99@gmail.com

Difficulty: Major

Potential mentors:

Yuelin ZhengMing Wen, mail: firstsawyou wenming (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Apache APISIX:

enhanced authentication for DashboardApache APISIX

Support Nacos in a native way

Apache APISIX is a dynamic, real-time, high-performance cloud-native API gateway, based on the Nginx library and etcd.

Page: https://apisix.apache.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

At present, Apache APISIX Dashboard only supports simple username and password login, we need a universal authentication mechanism that can connect to user's existing identity provider.

Task

org
Github: https://github.com/apache/apisix

Background

To get the upstream information dynamically, APISIX need to be integrated with other service discovery systems. Currently we already support Eureka, and many people hope we can support Nacos too.

Nacos is a widely adopted service discovery system: https://nacos.io/en-us/index.html

Previously we try to support Nacos via DNS. Nacos provides a CoreDNS plugin to expose the information via DNS: https://github.com/nacos-group/nacos-coredns-plugin

However, this plugin seems to be unmaintained.

Therefore, it would be good if we can support Nacos natively via its API, which is expected to be maintained.

Task

Integrate Nacos with APISIX via Nacos's HTTP API.

Relevant Skills

1. Master Lua language and HTTP protocol
2. Have a basic understanding of APISIX / Nacos

Targets files

1. In the Apache APISIX dashboard (https://github.com/apache/apisix-dashboard) project
1. Implement a universal login class
2. Support LDAP connection
3. Support OAuth2 connection

Relevant Skills
1. Golang
2. TypeScript
3. Be familiar with ETCD

/tree/master/apisix/discovery

References

1. Nacos Open API: https://nacos.io/en-us/docs/open-api.html

Mentor

Zexuan Luo, committer of Apache APISIX

spacewander@apache.org^{Image Added}Mentor
Junxu Chen, PMC of Apache APISIX, chenjunxu@apache.org

Difficulty: Major

Potential mentors:

Junxu ChenZexuan Luo, mail: chenjunxu spacewander (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Record short videos about Apache APISIX

: support to fetch more useful information of client request

What's
Apache APISIX
?
Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.
APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.
Background (route matching and run plugins)
When the client completes a request, there is a lot of useful information inside library and etcd, and we have a standalone website to let more people know about the Apache APISIX.
Image Removed
Task
Needs a way to show it. It is convenient for callers to troubleshoot problems and understand the workflow of Apache APISIX.
The first version target can display:
1. Which route is matched.
2. Which plugins are loaded.
In subsequent versions, we will add more information that the caller cares about, such as:
Whether the global plugin is executed
Time consumption statistics
The return value when the plugin is executed
Relevant Skills
Background
Apache APISIX has the official website[1], we would like to record more videos about How Apache APISIX works, What Apache APISIX is, How to write plugins for Apache APISIX, etc, to help more users to know what & how Apache APISIX works
Task
Draft the video list outline (I will provide it);
To read & try to use Apache APISIX docs, we must clearly know what it is;
Record videos (30 videos IMO).
Relevant Skills
Read Docs;
will use FinalCut or PR;
Know about Apache APISIX;
Mentor
Zhiyuan, PMC of Apache APISIX, juzhiyuan@apache.org
[1] https://apisix.apache.org/1. Master Lua language
2. Have a basic understanding of API Gateway or Web server
Difficulty: Major
Potential mentors:
YuanSheng WangZhiyuan, mail: membphis juzhiyuan (at) apache.org
Project Devs, mail: dev (at) apisix.apache.org

Apache APISIX:

support apply certificates from Let’s Encrypt or any other ACMEv2 service

Enhanced verification for APISIX ingress controller

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

The data plane of Apache APISIX supports dynamic loading of ssl certificates, but the control plane does not have the support of ACME.
Although users can use other tools to obtain ACME certificates, and then call the admin API to write them into Apache APISIX, this is not convenient for many users.

Task

In the Apache APISIX dashboard (https://github.com/apache/apisix-dashboard) project, add support for ACME, which can automatically obtain and update certificates

We can use APISIX as kubernetes ingress.Use CRD (Custom Resource Definition) on kubernetes to define APISIX objects, such as route/service/upstream/plugins.

We have done basic structural verification of CRD, but we still need more verification. For example, plug-in schema verification, dependency verification between APISIX objects, rule conflict verification, etc. All these verifications need to be completed before CRD is applied.

Task

1. Implement a validating admission webhook.
2. Support plugins schema verification.
3. Support object dependency verification.

Relevant Skills

1. Golang
2. Be Relevant Skills
TypeScript
Golang
familiar with Apache APISIX's admin API
3. Be familiar with kubernetes

Mentor

Ming WenWei Jin, PMC of Apache APISIX, wenming@apachekvn@apache.org

Difficulty: Major

Potential mentors:

Ming WenWei Jin, mail: wenming kvn (at) apache.org

Project Devs, mail: dev (at) apisix.apache.orgorg

Apache APISIX: improve the website

Apache APISIX

: Support Nacos in a native way

Apache APISIX is a dynamic, real-time, high-performance

cloud-native

API gateway, based on the Nginx library and etcd

.

Page: https://apisix.apache.org
Github: https://github.com/apache/apisix

Background

To get the upstream information dynamically, APISIX need to be integrated with other service discovery systems. Currently we already support Eureka, and many people hope we can support Nacos too.

Nacos is a widely adopted service discovery system: https://nacos.io/en-us/index.html

Previously we try to support Nacos via DNS. Nacos provides a CoreDNS plugin to expose the information via DNS: https://github.com/nacos-group/nacos-coredns-plugin

However, this plugin seems to be unmaintained.

Therefore, it would be good if we can support Nacos natively via its API, which is expected to be maintained.

Task

Integrate Nacos with APISIX via Nacos's HTTP API.

Relevant Skills

1. Master Lua language and HTTP protocol
2. Have a basic understanding of APISIX / Nacos

Targets files

1. https://github.com/apache/apisix/tree/master/apisix/discovery

References

1. Nacos Open API: https://nacos.io/en-us/docs/open-api.html

Mentor

Zexuan Luo, committer of Apache APISIX

, and we have a standalone website to let more people know about the Apache APISIX.

Background

The website of Apache APISIX is used for showing people what's Apache APISIX is, and it will include up to date docs to let developers searching guides more easily, and so on.

Task

In the website[1] and its repo[2], we are going to refactor the homepage, improve those docs which include apisix's docs and some like release guide.

Relevant Skills
TypeScript

React.js

Mentor

Zhiyuan, PMC of Apache APISIX, juzhiyuan@apache.org

[1] https://apisix.apache.org/

[2]https://github.com/apache/apisix-website spacewander@apache.org^{Image Removed}

Difficulty: Major

Potential mentors:

Zexuan LuoZhiyuan, mail: spacewander juzhiyuan (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Record short videos about

Apache APISIX Dashboard: Enhancement plugin orchestration

The Apache APISIX Dashboard is designed to make it as easy as possible for users to operate Apache APISIX through a frontend interface.

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd, and we have a standalone website to let more people know about the Apache APISIX.

Background

Apache APISIX has the official website[1], we would like to record more videos about How Apache APISIX works, What Apache APISIX is, How to write plugins for Apache APISIX, etc, to help more users to know what & how Apache APISIX works

Task

Draft the video list outline (I will provide it);
To read & try to use Apache APISIX docs, we must clearly know what it is;
Record videos (30 videos IMO).

Relevant Skills

Read Docs;
will use FinalCut or PR;
Know about Apache APISIX;

Mentor

Zhiyuan, PMC of Apache APISIX, juzhiyuan@apache.org

The Dashboard is the control plane and performs all parameter checks; Apache APISIX mixes data and control planes and will evolve to a pure data plane.

This project includes manager-api, which will gradually replace admin-api in Apache APISIX.

Background

The plugin orchestration feature allows users to define the order of plugins to meet their scenarios. At present, we have implemented the plugin scheduling feature, but there are still many points to be optimized.

Task

develop a new plugin, conditional judgment card style. Currently, both the conditional judgment card and the plug-in card are square shaped, which makes it difficult for users to distinguish them, so in this task the conditional judgment card needs to be changed to a diamond shape. As shown in the figure below. Image Added 2. Add arrows for connecting lines.The connection lines in the current plugin orchestration are not directional, we need to add arrows to the connection lines as shown in the figure below. Image Added 3. Limit plugin orchestration operations. We need to restrict the connection of each card to ensure the proper use of the plugin orchestration, and the situation shown in the arrow below is not allowed.

Image Added

Relevant Skills

1. Basic use of HTML, CSS, and JavaScript.

2. Basic use of React Framework.

Mentor

Yi Sun, committer of Apache APISIX,sunyi@apache.org^{Image Added}
[1] https://apisix.apache.org/

Difficulty: Major

Potential mentors:

ZhiyuanYi Sun, mail: juzhiyuan sunyi (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Apache APISIX:

Enhanced verification for APISIX ingress controller

Support invoke an AWS Lambda function through plugin

Apache APISIX: Support invoke an AWS Lambda function through plugin

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

We can use APISIX as kubernetes ingress.Use CRD (Custom Resource Definition) on kubernetes to define APISIX objects, such as route/service/upstream/plugins.

We have done basic structural verification of CRD, but we still need more verification. For example, plug-in schema verification, dependency verification between APISIX objects, rule conflict verification, etc. All these verifications need to be completed before CRD is applied.

Task

1. Implement a validating admission webhook.
2. Support plugins schema verification.
3. Support object dependency verification.

Relevant Skills

1. Golang
2. Be familiar with Apache APISIX's admin API
3. Be familiar with kubernetes

Mentor

Wei Jin, PMC of Apache APISIX, kvn@apache.org

Difficulty: Major

Potential mentors:

Wei Jin, mail: kvn (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Apache APISIX: improve the website

Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcd, and we have a standalone website to let more people know about the Apache APISIX.

Background

The website of Apache APISIX is used for showing people what's Apache APISIX is, and it will include up to date docs to let developers searching guides more easily, and so on.

Task

In the website[1] and its repo[2], we are going to refactor the homepage, improve those docs which include apisix's docs and some like release guide.

Relevant Skills
TypeScript

React.js

Mentor

Zhiyuan, PMC of Apache APISIX, juzhiyuan@apache.org

[1] https://apisix.apache.org/

[2]https://github.com/apache/apisix-website

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes: https://aws.amazon.com/lambda/

We can create a plug-in for AWS Lambda, including authentication with AWS, trigger lambda function, and get the return result of lambda function.So that we can trigger lambda more securely and more easily.

Task

In the Apache APISIX (https://github.com/apache/apisix) project, implement a plug-in with the following functions:

Authentication with AWS
Trigger lambda function
Get the response from AWS Lambda

Relevant Skills

Master Lua language;
Have a basic understanding of API Gateway or Web server;

Mentor

Xinxin Zhu, committer of Apache APISIX

starsz@apache.org

Difficulty: Major

Potential mentors:

ZhiyuanPeter Zhu, mail: juzhiyuan starsz (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org.apache.org

Integrate Cert-Manager to APISIX Ingress Controller

Apache APISIX

Dashboard: Enhancement plugin orchestration

The Apache APISIX Dashboard is designed to make it as easy as possible for users to operate Apache APISIX through a frontend interface.
The Dashboard is the control plane and performs all parameter checks; Apache APISIX mixes data and control planes and will evolve to a pure data plane.
This project includes manager-api, which will gradually replace admin-api in Apache APISIX.

Background

The plugin orchestration feature allows users to define the order of plugins to meet their scenarios. At present, we have implemented the plugin scheduling feature, but there are still many points to be optimized.

Task

develop a new plugin, conditional judgment card style. Currently, both the conditional judgment card and the plug-in card are square shaped, which makes it difficult for users to distinguish them, so in this task the conditional judgment card needs to be changed to a diamond shape. As shown in the figure below. Image Removed 2. Add arrows for connecting lines.The connection lines in the current plugin orchestration are not directional, we need to add arrows to the connection lines as shown in the figure below. Image Removed 3. Limit plugin orchestration operations. We need to restrict the connection of each card to ensure the proper use of the plugin orchestration, and the situation shown in the arrow below is not allowed.

Image Removed

Relevant Skills

1. Basic use of HTML, CSS, and JavaScript.

2. Basic use of React Framework.

Mentor

Yi Sun, committer of Apache APISIX,sunyi@apache.org^{Image Removed}

a dynamic, real-time, high-performance API gateway, based on the Nginx library and etc.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

Cert-Manager (https://cert-manager.io/docs/installation/kubernetes/) helps to to deliver and rotate certificates dynamically; While apisix-ingress-controller has a CRD resource ApisixTls which supports configuring certificate from Kubernetes Secrets (https://kubernetes.io/docs/concepts/configuration/secret/) dynamically, the secret itself, still need to be created by administrators themselves.

So here has an opportunity to integrate Cert-Manager and apisix-ingress-controller, let the Cert-Manager maintains the Secret (update it once the certificate changed), and let apisix-ingress-controller watches the newest change and apply the newest certificate (and the private key). This integration reduces the complexity of the maintaining of the apisix-ingress-controller.

Task

Research Cert-Manager and its ACME issuer
Add new design in the CRD ApisixTls, let it support integrating Cert-Manager
Coding on apisix-ingress-controller, implementing the new version ApisixTls and creates a certificate request when an ApisixTls resource was created.

Relevant Skills

Golang
Have basic learning about Kubernetes, Ingress, and ingress controller.

Mentor

Chao Zhang, PMC of Apache APISIX, tokers@apache.org

Difficulty: Major

Potential mentors:

Yi SunChao Zhang, mail: sunyi tokers (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Exposing more Prometheus Metrics for Apache APISIX

: Support invoke an AWS Lambda function through plugin

Ingress Controller

Apache APISIX

: Support invoke an AWS Lambda function through plugin

Apache APISIX Apache APISIX is a dynamic, real-time, high-performance API gateway, based on the Nginx library and etcdetc.
APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
You can use Apache APISIX to handle traditional north-south traffic, as well as east-west traffic between services. It can also be used as a k8s ingress controller.

Background

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes: https://aws.amazon.com/lambda/

We can create a plug-in for AWS Lambda, including authentication with AWS, trigger lambda function, and get the return result of lambda function.So that we can trigger lambda more securely and more easily.

Task

In the Apache APISIX (https://github.com/apache/apisix) project, implement a plug-in with the following functions:

Authentication with AWS
Trigger lambda function
Get the response from AWS Lambda

Relevant Skills

Master Lua language;
Have a basic understanding of API Gateway or Web server;

Mentor

Xinxin Zhu, committer of Apache APISIX

Metrics in the apisix ingress controller is less, which results in the observability of the controller itself is bad (though the data plane (i.e. APISIX itself) has rich metrics), therefor we need more and more metrics for apisix ingress controller, and show them in Grafana.

Task

Plan which metrics should be exported in apisix-ingress-controller
Coding on apisix-ingress-controller, adding these hooks for the aggregation of metrics.
Integrating with Grafana.

Relevant Skills

Golang
Be familiar with Prometheus
Have basic understandings of Kubernetes, Ingress, and Ingress Controllers.

Mentor

Chao Zhang, PMC of Apache APISIX, tokers@apachestarsz@apache.org

Difficulty: Major

Potential mentors:

Peter ZhuChao Zhang, mail: starsz tokers (at) apache.org

Project Devs, mail: dev (at) apisix.apache.org

Space shortcuts

Child pages

Page History

Versions Compared

Key

Syncope

Clerezza

CloudStack

Cassandra

Clerezza

Cassandra

Beam

Apache NuttX

Apache Hudi

Beam

Apache NuttX

Apache Fineract

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Apache Hudi

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Apache Fineract

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Sample APIs to be Documented

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Sample APIs to be Documented

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives

Description

Helpful Skills

Impact

Other Resources

Mentors

Overview & Objectives