THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Contents
...
Improve the message backlogs for the topic
In Pulsar, the client usually sends several messages with a batch. From the broker side, the broker receives a batch and write the batch message to the storage layer.
The message backlog is maintaining how many messages should be handled for a subscription. But unfortunately, the current backlog is based on the batches, not the messages. This will confuse users that they have pushed 1000 messages to the topic, but from the subscription side, when to check the backlog, will return a value that lower than 1000 messages such as 100 batches. Not able to get the message based backlog is it's so expensive to calculate the number of messages in each batch.
PIP-70 https://github.com/apache/pulsar/wiki/PIP-70%3A-Introduce-lightweight-raw-Message-metadata Introduced a broker level entry metadata which can support message index for a topic(or message offset of a topic). This will provide the ability to calculate the number of messages between a message index to another message index. So we can leverage PIP-70 to improve the message backlog implementation to able to get the message-based backlog.
For the Exclusive subscription or Failover subscription, it easy to implement by calculating the messages between the mark delete position and the LAC position. But for the Shared and Key_Shared subscription, the individual acknowledgment will bring some complexity. We can cache the individual acknowledgment count in the broker memory, so the way to calculate the message backlog for the Shared and Key_Shared subscription is `backlogOfTheMarkdeletePosition` - `IndividualAckCount`
Difficulty: Major
Potential mentors:
Penghui Li, mail: penghui (at) apache.org
Project Devs, mail:
James Server
OODT
Improve OPSUI React.js UI with advanced functionalities
In GSoC 2019, we implemented a new OPSUI UI based on React.js. See the related blog posts [1] [2]. Several advanced features require to be implemented including.
- Implement querying functionality at OPSUI side (scope can be determined)
- Show progress of workflows and file ingestions
- Introduce a proper REST API for resource manager component
- Introduce proper packaging (with configurable external REST API URLs) and deployment mechanism (as a docker deployment or an npm package)
In this project, the student will have to work on the UI with React.js and will have to implement several REST APIs using JAX-RS. Furthermore, will have to work on making OPSUI easy to deploy.
The existing wicket based OPSUI will be replaced by the new React.js based OPSUI at the end of this project. And the linked blog posts will be a good start to understand what the new React.js based OPSUI is capable of doing.
[1] https://medium.com/faun/gsoc-2019-apache-oodt-react-based-opsui-dashboard-d93a9083981c
[2] https://medium.com/faun/whats-new-in-apache-oodt-react-opsui-dashboard-4cc6701628a9
[3] https://medium.com/faun/apache-oodt-with-docker-84d32525c798
[GSOC-2021] Implement Thread support for JMAP
Why ?
Mail user agents generally allow displaying emails grouped by conversations (replies, forward, etc...).
As part of JMAP RFC-8621 implementation, there is a dedicated concepts: threads. We did implement JMAP Threads in a rather naive way: each email is a thread of its own.
This naive implementation is specification compliant but defeat the overall purposes of threads.
I propose myself to mentor the implementation of Threads as part of the James JMAP implementation.
Difficulty: Major
Potential mentors:
Benoit TellierImesha Sudasingha, mail: btellier imesha (at) apache.org
Project Devs, mail:
Fineract Cloud Native
James Server
[GSOC-2021] Implement Thread support for JMAP
Why ?
Mail user agents generally allow displaying emails grouped by conversations (replies, forward, etc...).
As part of JMAP RFC-8621 implementation, there is a dedicated concepts: threads. We did implement JMAP Threads in a rather naive way: each email is a thread of its own.
This naive implementation is specification compliant but defeat the overall purposes of threads.
I propose myself to mentor the implementation of Threads as part of the James JMAP implementation.
Difficulty: Major
Potential mentors:
Benoit Tellier, mail: btellier (at) apache.org
Project Devs, mail:
Fineract Cloud Native
Functional Enhancements to Fineract CN Mobile
Functional Enhancements to Fineract CN Mobile
Mentors
Overview & Objectives
Just as we have a mobile field operations app on Apache Fineract 1.x, we have recently built out on top of the brand new Apache Fineract CN micro-services architecture, an initial version of a mobile field operations app with an MVP architecture and material design. Given the flexibility of the new architecture and its ability to support different methodologies - MFIs, credit unions, cooperatives, savings groups, agent banking, etc - this mobile app will have different flavors and workflows and functionalities.
Description
In 2020, our Google Summer of Code intern worked on additional functionality in the Fineract CN mobile app. In 2021, the student will work on the following tasks:
- Integrate with Payment Hub to enable disbursement via Mobile Money API
- Improve Task management features into the app.
- Create UI for creating new account and displaying account details
- Create UI for creating tellers and displaying tellers details
- Improve GIS features like location tracking, dropping of pin into the app
- Improve offline mode via Couchbase support
- Write Unit Test, Integration Test and UI tests
Helpful Skills
Android Development, Kotlin, Java, Git, OpenJPA, Rest API
Impact
Allows staff to go directly into the field to connect to the client. Reduces cost of operations by enabling organizations to go paperless and be more efficient.
Other Resources
- Repo on Github:
https://github.com/apache/fineract-cn-mobile - Fineract CN API documentation:
https://izakey.github.io/fineract-cn-api-docs-site/ - https://github.com/aasaru/fineract-cn-api-docs
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN - How to install and run Couchbase:
https://gist.github.com/jawidMuhammadi/af6cd34058cacf20b100d335639b3ad8 - GSMA mobile money API:
https://developer.mobilemoneyapi.io/1.1/oas3/22466 - Payment Hub:
https://github.com/search?q=openMF%2Fph-ee&ref=opensearch - Some UI designs:
https://www.figma.com/file/KHXtZPdIpC3TqvdIVZu8CW/fineract-cn-mobile?node-id=0%3A1
Difficulty: Major
Potential mentors:
Ed Cable, mail: edcable (at) apache.org
Project Devs, mail: dev (at) fineract.apache.org
...
Integrating Apache IoTDB and Apache Superset
Apache IoTDB [1] is an Open Source IoT database designed to meet the rigorous data, storage, and analytics requirements of large-scale Internet of Things (IoT) and Industrial Internet of Things (IIoT) applications.
Apache Superset [2] is fast, lightweight, intuitive, and loaded with options that make it easy for users of all skill sets to explore and visualize their data, from simple line charts to highly detailed geospatial charts.
We hope that Superset can be used as a data display and analysis tool of IoTDB, which will bring great convenience to analysts of the IoT and IIoT.
For a database engine to be supported in Superset, it requires having a Python compliant SQLAlchemy dialect [3] as well as a DBAPI driver [4] defined. The current Python client of IoTDB is packaged by Apache Thrift generated code and does not follow a certain interface specification. Therefore, the first thing you need to do is to implement a standard SQLAlchemy connector based on the current Python client (or some new interfaces defined and generated by Thrift).
Next, you need to explore how to integrate IoTDB and Superset and document the usage in a user-friendly way. The integration documentation for Apache Kylin and Superset is here [5] for your reference.
What knowledge you need to know:
- Basic database knowledge (SQL)
- Python
[1] https://iotdb.apache.org
[2] https://superset.apache.org/
[3] https://docs.sqlalchemy.org/en/13/dialects/
[4] https://www.python.org/dev/peps/pep-0249/
[5] http://kylin.apache.org/blog/2018/01/01/kylin-and-superset/
Difficulty: Major
Potential mentors:
Xiangdong Huang, mail: hxd (at) apache.org
Project Devs, mail:
TrafficControl
Apache IoTDB: GUI workbench
Apache IoTDB [1] is an Open Source IoT database designed to meet the rigorous data, storage, and analytics requirements of large-scale Internet of Things (IoT) and Industrial Internet of Things (IIoT) applications.
As a database, it is good to have a workbench to operate IoTDB using a GUI.
For example, there is a 3rd-part web-based workbench for Apache Cassandra [2]. MySQL supports a more complex workbench application [3].
We also want to IoTDB has a workbench.
Task:
1. execute SQL and show results in Table or Chart.
2. view the schema of IoTDB (how many Storage groups, how many time series etc..)
3. View and modify IoTDB's configuration
4. View IoTDB's dynamic status (e.g., info that JMX can get)
(As we have integrated IOTDB with Apache Zeppelin, task 1 has done. So, we hope this workbench can be more lightweight than using Zeppelin.)
Better to use Java. (Python or some others are also ok).
Needed Skills:
- Java
- Web application development
[1] iotdb.apache.org
[2] https://github.com/avalanche123/cassandra-web
[3] https://www.mysql.com/cn/products/workbench/
Difficulty: Major
Potential mentors:
Xiangdong Huang, mail: hxd (at) apache.org
Project Devs, mail:
TrafficControl
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
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
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
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
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
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:
Difficulty: Major
Potential mentors:
Eric FriedrichRohit Yadav, mail: friede bhaisaab (at) apache.org
Project Devs, mail: dev (at) trafficcontrolcloudstack.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:
...