Project title:

Multiple programming languages client SDK support with OpenAPI generator.

Apache APISIX is a dynamic, real-time, high-performance API gateway.

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

Page: https://apisix.apache.org/

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

Background:

OpenAPI Generator allows the generation of API client libraries (SDK generation), server stubs, documentation, and configuration automatically given an OpenAPI Spec.

We can use it to provide Apache APISIX Admin and Control API SDKs in multiple programming languages. In the future, we may potentially integrate Java SDK into Spring framework and the starter of Spring boot or even make integration with ASP .Net

Task:

Generate a multilingual SDK through the definition files of the OpenAPI specification and use the OpenAPI Generator tool to generate client SDKs for Admin and Control APIs.

Difficulty: Normal
Project size: ~350 hours.

References:

• https://swagger.io/tools/swagger-codegen/
• https://github.com/OpenAPITools/openapi-generator

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.

Apache APISIX is a dynamic

Project title:

Multiple programming languages client SDK support with OpenAPI generator.

Apache APISIX is a dynamic, real-time, high-performance API gateway.

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

Page: https://apisix.apache.org/

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

Background:

OpenAPI Generator allows the generation of API client libraries (SDK generation), server stubs, documentation, and configuration automatically given an OpenAPI Spec.

We can use it to provide Apache APISIX Admin and Control API SDKs in multiple programming languages. In the future, we may potentially integrate Java SDK into Spring framework and the starter of Spring boot or even make integration with ASP .Net

Task:

Project title:

Datacenter and local file configuration conversion, export and import are supported via Apache APISIX CLI.

Background: 

Apache APISIX supports running in standalone mode. At this point, Apache APISIX will rely on the local configuration file `conf/apisix.yaml` for routing and policy settings.

Apache  APISIX CLI supports the conversion, import and export of data center and local file configuration data, making Apache APISIX easier to switch and apply between different environments and scenarios.

Task: 

Add two commands `bin/apisix conf_export` and `bin/apisix conf_import` to Apache APISIX CLI, and complete the conversion, import and export of remote data center and local file configuration data through the above commandsGenerate a multilingual SDK through the definition files of the OpenAPI specification and use the OpenAPI Generator tool to generate client SDKs for Admin and Control APIs.

Difficulty: Normal
Project size: ~350  ~350 hours.

References:

https://

github.

com/apache/

apisix/

blob/master/docs/en/latest/stand-alone.md

Background:

At the moment, the Java runner plugin requires you to use an existing template project and change it according to one’s needs.

Task:

Improve developer experience on the existing Java plugin runner so that we can attract and increase the number of users from the Java community.

Limitations:

• The architecture doesn’t manage multiple plugins. All need to be set in the same project
• The standard Java unit of deployment is the JAR.
• The plugin doesn’t allow for other widespread JVM-based languages (e.g., Scala, Kotlin, Clojure, Groovy). Though it would be technically feasible, we would need to change the template’s language

Requirements:

The new plugin runner:

• MUST use the JAR as the unit of deployment
• MUST not require the usage of a project template
• MAY require the plugin to follow a certain class hierarchy (i.e., extends JavaPlugin)
• MAY use a more specific format to enforce a structure
• MUST allow multiple plugins to be deployed

• MUST use isolated classloader for each plugin
• MUST allow any JVM-compatible bytecode to run, whatever the language it was generated from
• MAY allow hot reloading of Java plugins
• MAY require a single JAR per plugin (to ease the classpath management of shared libraries)
• MUST define a minimum JVM version

Difficulty: Normal
Project size: ~350 hours.

Placeholder for tasks that could be undertaken in this year's GSoC.

Ideas (extracted from the "dev" ML):

1. Redesign and modularize the "ml" package
   -> main goal: enable multi-thread usage.
2. Abstract the linear algebra utilities
   -> main goal: allow switching to alternative implementations.
3. Redesign and modularize the "random" package
   -> main goal: general support of low-discrepancy sequences.
4. Refactor and modularize the "special" package
   -> main goals: ensure accuracy and performance and better API,
   add other functions.
5. Upgrade the test suite to Junit 5
   -> additional goal: collect a list of "odd" expectations.

Other suggestions welcome, as well as

• delineating additional and/or intermediate goals,
• signalling potential pitfalls and/or alternative approaches to the intended goal(s).

Currently Apache SkyWalking can collect logs from various sources like user agents and Envoy access logs, it also provides a log analysis language to analyze the logs and produce some metrics, with those metrics, users can configure rules to trigger alerts and react to those abnormal/exceptional logs.

But in reality, production environment exceptional logs are not known in advance and users can't enumerate all possible exceptional logs.

This task aims to add an algorithm that can identify outlier log(s) from the massive logs, and draw the users attention to see whether there is error in the system.

The algorithm should be able to learn from bot the history logs and streaming logs, and adjust itself to increase the accuracy.

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.

Placeholder for tasks that could be undertaken in this year's GSoC.

Ideas:

• Update the support for complex numbers in the complex package to allow operations to be performed on lists of complex numbers. This requires abstracting the representation of multiple complex numbers into a list structure storing real and imaginary parts that can be efficiently iterated to apply all the operations supported by the Complex class. Operations should modify the numbers in place allowing efficient, zero allocation complex number math to be performed on large datasets.

Placeholder for tasks that could be undertaken in this year's GSoC.

Ideas (extracted from the "dev" ML):

1. Redesign and modularize the "ml" package
   -> main goal: enable multi-thread usage.
2. Abstract the linear algebra utilities
   -> main goal: allow switching to alternative implementations.
3. Redesign and modularize the "random" package
   -> main goal: general support of low-discrepancy sequences.
4. Refactor and modularize the "special" package
   -> main goals: ensure accuracy and performance and better API,
   add other functions.
5. Upgrade the test suite to Junit 5
   -> additional goal: collect a list of "odd" expectations.

Other suggestions welcome, as well as

• delineating additional and/or intermediate goals,
• signalling potential pitfalls and/or alternative approaches to the intended goal(s).

It would be desirable to develop a Beam Sink that supports all of the 'best practices' like throttling, auto-sharding, exactly-once capabilities, etc.

A design proposal is here: https://docs.google.com/document/d/1UIWv6wnD86GYAkeqbVWCG3mx4dTZ9WstUUThPWQmcFM/edit#heading=h.smc16ifdre2

A prototype for the API and parts of implementation is here: https://github.com/apache/beam/pull/16763

Contact Pablo Estrada on dev@beam.apache.org^{Image Removed} if you have questions, or comment here.

In Stream processing, we have many methods, starting from the primitive checkpoint-and-replay to a more fancy version of reconfiguration and reinitiation of stream workloads. We aim to find a way to find the most effective and efficient way of reconfiguring stream workloads. Sub-issues are to be created later on.

Nemo has a policy layer that allows powerful optimization with configurable runtime modules. In terms of caching, it is possible to identify frequently used data and decide to cache them in-memory ahead of execution, without user annotation.

Implementation would need:

• On policy layer, build compile-time pass that identify reused data and mark them as cached
• On runtime, design and implement caching mechanism that manages per-executor cached data and discard them when these are no longer used.