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).

Background

Terraform is an Infrastructure as Code (IaC) software that provides a consistent CLI workflow to manage resources in
many cloud services. Cloudstack Terraform provider integrates with Cloudstack to aid in managing and automating the deployment of resources in cloudstack. We have recently made the first release of CloudStack Terraform Provider v0.4.0 https://github.com/apache/cloudstack-terraform-provider

Requirement

Terraform defines a datasource as, "something that allows Terraform to use the information defined outside of Terraform, defined by another separate Terraform configuration, or modified by functions". Most resources offer data sources alongside their set of resource types. However, currently Cloudstack Terraform Provider only has one datasource for template. Hence, we propose an idea for students to get involved in enhancing the features of the Cloudstack Terraform Provider by adding support for datasources.

Image Removed

If the students are enjoying the project, the scope can be extended to support adding further resources in Terraform such that the CloudStack Terraform Provider may become a de-facto tool for automating CloudStack deployments.

The current set of resources Cloudstack terraform provider supports are:
https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs , where as its counterpart Ansible boasts of a more evolved list of resources  https://docs.ansible.com/ansible/latest/collections/ngine_io/cloudstack/index.html  mainly zones, clusters, accounts, domains, etc. It would be great if students interested want to go a step ahead and help add support for these too.

Relevant Skills:

GoLang (basic)

Difficulty:

Medium

Potential Mentors:

Harikrishna Patnala
Pearl Dsilva

Example and references

https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs : check Resources and Data Sources section under CloudStack Provider
Depends on CloudStack Go SDK - https://github.com/apache/cloudstack-go

Github issue: https://github.com/apache/cloudstack/issues/6016

Background

The default way of registering / downloading templates in CloudStack involves caching them on the secondary store and then during VM deployment, the template is copied to the primary store. However, from ACS version 4.11.1 onward, a feature was added for KVM hypervisor to enable direct download to primary store. This massively reduces the usage of secondary store and also quickens the entire VM deployment process, as there is no need to copy the template from secondary to primary store. 

Requirement

We

Background

Over recent years, Edge computing has been gaining popularity as it defines a model that brings compute and storage closer to
where they are consumed by the end-user. By being closer to the end-user a better experience can be provided with reduction on overall latency, lower bandwidth requirements, lower TCO, more flexible hardware/software model, while also ensuring security and reliability. To align ACS with this evolving cloud computing model we would like to propose an idea of supporting Edge Zones in CloudStack, which
can be also looked upon as a lightweight zone, with minimal resources.

Requirement

Today, when a Zone is setup in CloudStack, it by default comes up with a secondary storage VM(SSVM) and a console proxy VM(CPVM). As part of this project, we would need to define a new zone type to decide the change in workflow required to ensure that a CPVM & SSVM isn't spawned up by default. Basic characteristics of an Edge zone include:

• no need for Secondary Storage
• no Secondary Storage VM
• no Console Proxy VM
• Local storage only as typically an edge device comprises of a single compute node (host)
• And supports L2 and Isolated networks.

A high-level view of an edge zone would look something like:

Image Removed

Relevant Skills:

Java
MySQL
Vue.js (Basic)

Difficulty:

Medium

Project Duration:

175 hours

Potential Mentors:

Alex Mattioli
Nicolas Vazquez
Pearl Dsilva

to extend this feature of direct download of templates onto primary store for other hypervisors - namely, VMware and XenServer. This would gravely benefit end-users to efficiently use the secondary storage and save overall time of VM deployment on the respective hypervisors

Relevant Skills:

Java
MySQL
Vue.js

Difficulty:

175 hours (Only VMware)
350 hours (VMware & XenServer)

Potential Mentors:

Abhishek Kumar (abhishek.mrt22@gmail.com)
Pearl Dsilva (pearl1594@gmail.com)

References

https://www.shapeblue.com/how-to-deploy-templates-without-using-secondary-storage-on-kvm/
https://www.shapeblue.com/cloudstack-feature-first-look-direct-download-agnostic-of-the-storage-provider/
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bypass+Secondary+Storage+%28Direct+Download%29+on+KVM
https://www.youtube.com/watch?v=SwepUTfGiKc

Background

Terraform is an Infrastructure as Code (IaC) software that provides a consistent CLI workflow to manage resources in
many cloud services. Cloudstack Terraform provider integrates with Cloudstack to aid in managing and automating the deployment of resources in cloudstack. We have recently made the first release of CloudStack Terraform Provider v0.4.0 https://github.com/apache/cloudstack-terraform-provider

Requirement

Terraform defines a datasource as, "something that allows Terraform to use the information defined outside of Terraform, defined by another separate Terraform configuration, or modified by functions". Most resources offer data sources alongside their set of resource types. However, currently Cloudstack Terraform Provider only has one datasource for template. Hence, we propose an idea for students to get involved in enhancing the features of the Cloudstack Terraform Provider by adding support for datasources.

Image Added

If the students are enjoying the project, the scope can be extended to support adding further resources in Terraform such that the CloudStack Terraform Provider may become a de-facto tool for automating CloudStack deployments.

The current set of resources Cloudstack terraform provider supports are:
https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs , where as its counterpart Ansible boasts of a more evolved list of resources  https://docs.ansible.com/ansible/latest/collections/ngine_io/cloudstack/index.html  mainly zones, clusters, accounts, domains, etc. It would be great if students interested want to go a step ahead and help add support for these too.

Relevant Skills:

GoLang (basic)

Difficulty:

Medium

Potential Mentors:

Harikrishna Patnala
Pearl Dsilva

Example and references

https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs : check Resources and Data Sources section under CloudStack Provider
Depends on CloudStack Go SDK - https://github.com/apache/cloudstack-go

Github issue: https://github.com/apache/cloudstack/issues/6016

Background

The default way of registering / downloading templates in CloudStack involves caching them on the secondary store and then during VM deployment, the template is copied to the primary store. However, from ACS version 4.11.1 onward, a feature was added for KVM hypervisor to enable direct download to primary store. This massively reduces the usage of secondary store and also quickens the entire VM deployment process, as there is no need to copy the template from secondary to primary store. 

Requirement

We would like to propose an idea to extend this feature of direct download of templates onto primary store for other hypervisors - namely, VMware and XenServer. This would gravely benefit end-users to efficiently use the secondary storage and save overall time of VM deployment on the respective hypervisors

Relevant Skills:

Java
MySQL
Vue.js

Difficulty:

175 hours (Only VMware)
350 hours (VMware & XenServer)

Potential Mentors:

Abhishek Kumar (abhishek.mrt22@gmail.com)
Pearl Dsilva (pearl1594@gmail.com)

References

https://www.shapeblue.com/how-to-deploy-templates-without-using-secondary-storage-on-kvm/
https://www.shapeblue.com/cloudstack-feature-first-look-direct-download-agnostic-of-the-storage-provider/
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bypass+Secondary+Storage+%28Direct+Download%29+on+KVM
https://www.youtube.com/watch?v=SwepUTfGiKc

Background

Over recent years, Edge computing has been gaining popularity as it defines a model that brings compute and storage closer to
where they are consumed by the end-user. By being closer to the end-user a better experience can be provided with reduction on overall latency, lower bandwidth requirements, lower TCO, more flexible hardware/software model, while also ensuring security and reliability. To align ACS with this evolving cloud computing model we would like to propose an idea of supporting Edge Zones in CloudStack, which
can be also looked upon as a lightweight zone, with minimal resources.

Requirement

Today, when a Zone is setup in CloudStack, it by default comes up with a secondary storage VM(SSVM) and a console proxy VM(CPVM). As part of this project, we would need to define a new zone type to decide the change in workflow required to ensure that a CPVM & SSVM isn't spawned up by default. Basic characteristics of an Edge zone include:

• no need for Secondary Storage
• no Secondary Storage VM
• no Console Proxy VM
• Local storage only as typically an edge device comprises of a single compute node (host)
• And supports L2 and Isolated networks.

A high-level view of an edge zone would look something like:

Image Added

Relevant Skills:

Java
MySQL
Vue.js (Basic)

Difficulty:

Medium

Project Duration:

175 hours

Potential Mentors:

Alex Mattioli
Nicolas Vazquez
Pearl Dsilva

As of now, when an admin encounters an issue or error in CloudStack, the maximum information they can immediately get is the API failure response which provides a reason for the failure. At times this might not be sufficinet to diagnose the error and would require the admin to investiage the CloudStack logs. This would require the admin or the sysadmin to log into the VM running CloudStack and either view or export the logs, and then dive into identifying the issue. This idea aims to eiliminate that step.

The goal of this is to provide admins the ability to view the logs directly in the UI. This would make diagnosing failures and RCAs much quicker.

Provide the ability display the logs in the UI

Add an API / WebSocket (and UI) support to :

• View the logs
• Live follow the logs (similar to 'tail -f')

Duration

• 175 hours

Potential Mentors

• David Jumani

References

• https://github.com/apache/cloudstack/issues/6011

Shutting down / Restarting Cloudstack is a necessary step in upgrades, system maintenance, etc. As of now, there is no way to safely shutdown or restart CloudStack. It is directly terminated via systemd. Since this is the case, any asyncronous job or background task is abrubptly terminated and can fail. As of now, CloudStack maintains a list of asynchronous jobs wihtin it's database along with their status.

This idea aims to provide a way to safely shutdown CloudStack. It involves two parts :

• Prevent new asynchronous jobs from being added to CloudStack when a safe shutdown is triggered
• Check the status of the async jobs and Shut down CloudStack when all the jobs have been completed

Provide the ability to safely shutdown CloudStack

Add API (and/or UI) support to :

• Trigger a safe shutdown
• (Optional) Support restarts
• (Optional) Support a forced shutdown when CloudStack will quit even if there are async jobs running

Duration

• Some Experience : 175 hours
• Newbie : 350 hours

Potential Mentors

• David Jumani

References

• https://github.com/apache/cloudstack/issues/6021

We should provide users a way to understand how their query will be executed and some information on the amount of work that will be performed.
Explain statements are the most common way to do that.
A CEP Draft has been open for that: (DRAFT) CEP-4: Explain. This draft propose to add support for EXPLAIN and EXPLAIN ANALYZE but I believe that we should split the work in 2 parts because a simple EXPLAIN would already provide relevant information.

To complete this work I believe that the following steps will be required:

• Rework and submit the CEP
• Add missing statistics
• Implements the logic behind the EXPLAIN statements

As of now the CloudStack Terraform Provider does not support managing CKS clusters

This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters

This would involve supporting the following actions on CKS clusters :

• Create
• Stop / Start
• Scale
• Upgrade
• Delete

[Optional]
Support the following actions on the binary ISOs :

• Register
• Enable / Disable
• Delete

Duration

• 175 hours

Potential Mentors

• Harikrishna Patnala
• David Jumani

References

• https://github.com/apache/cloudstack/issues/6040

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.

Discussion: https://lists.apache.org/thread.html/8aff7d70c254356f2dae3109fb605e0b60763602225a877d3dadf8b7@%3Cdev.beam.apache.org%3E

Summarizing that discussion, we have a lot of issues/wishes. Some can be addressed as one-off and some need a unified reorganization of the runner comparison.

Basic corrections:

• Remove rows that impossible to not support (ParDo)
• Remove rows where "support" doesn't really make sense (Composite transforms)
• Deduplicate rows are actually the same model feature (all non-merging windowing / all merging windowing)
• Clearly separate rows that represent optimizations (Combine)
• Correct rows in the wrong place (Timers are actually a "what...?" row)
• Separate or remove rows have not been designed ([Meta]Data driven triggers, retractions)
• Rename rows with names that appear no where else (Timestamp control, which is called a TimestampCombiner in Java)
• Switch to a more distinct color scheme for full/partial support (currently just solid/faded colors)
• Switch to something clearer than "~" for partial support, versus ✘ and ✓ for none and full.
• Correct Gearpump support for merging windows (see BEAM-2759)
• Correct Spark support for non-merging and merging windows (see BEAM-2499)

Minor rewrites:

• Lump all the basic stuff (ParDo, GroupByKey, Read, Window) into one row
• Make sections as users see them, like "ParDo" / "side Inputs" not "What?" / "side inputs"
• Add rows for non-model things, like portability framework support, metrics backends, etc

Bigger rewrites:

• Add versioning to the comparison, as in BEAM-166
• Find a way to fit in a plain English summary of runner's support in Beam. It should come first, as it is what new users need before getting to details.
• Find a way to describe production readiness of runners and/or testimonials of who is using it in production.
• Have a place to compare non-model differences between runners

Changes requiring engineering efforts:

• Gather and add quantitative runner metrics, perhaps Nexmark results for mid-level, smaller benchmarks for measuring aspects of specific features, and larger end-to-end benchmarks to get an idea how it might actually perform on a use case
• Tighter coupling of the matrix portion of the comparison with tags on ValidatesRunner tests

If you care to address some aspect of this, please reach out and/or just file a subtask and address it.

The existing compaction strategies have a number of drawbacks that make all three unsuitable as a general use compaction strategy, for example STCS creates giant files that are hard to back up, mess with read performance and the page cache, and led to many of the early re-open bugs. LCS improved dramatically on this but also has various issues e.g. lack of performant full compaction or due to the strict leveling with e.g. bulk loading when writes exceed the rate we can do the L0 - L1 promotion.

In this talk I proposed a novel compaction strategy that aims to expose a single tunable that the user can control for the read amplification. Raise the min_threshold_levels and you tradeoff read/space performance for write performance. Since then a proof of concept patch has been published along with some rudimentary documentation but this is still not tracked in Jira.

The remaining work here is

1. Validate the algorithm is correct via test suites and performance testing stress testing and benchmarking with OSS tools (e.g. cassandra-stress, tlp-stress, or ndbench). When issues are found (there likely will be issues as the patch is a PoC), devise how to adjust the algorithm and implementation appropriately. Key metric of success is we can run Cassandra stably for more than 24 hours while applying sustained load, with minimal compaction load (and also compaction can keep up).

2. Do more in depth experiments measuring performance across a wide range of workloads (e.g. write heavy, read heavy, balanced, time series, register update, etc ...) and in comparison with LCS (leveled), STCS (size tiered), and TWCS (time window). Key metrics of success are establishing that as we tune max_read_per_read we should get more predictable read latency under low system load (ρ < 30%) while not degrading at high system load (ρ > 70%), and we should match LCS performance under low load while doing better at high load.

Once this is validated a Cassandra blog post reporting on the findings (positive or negative) may be advisable.

We should provide users a way to understand how their query will be executed and some information on the amount of work that will be performed.
Explain statements are the most common way to do that.
A CEP Draft has been open for that: (DRAFT) CEP-4: Explain. This draft propose to add support for EXPLAIN and EXPLAIN ANALYZE but I believe that we should split the work in 2 parts because a simple EXPLAIN would already provide relevant information.

To complete this work I believe that the following steps will be required:

• Rework and submit the CEP
• Add missing statistics
• Implements the logic behind the EXPLAIN statements

Discussion: https://lists.apache.org/thread.html/8aff7d70c254356f2dae3109fb605e0b60763602225a877d3dadf8b7@%3Cdev.beam.apache.org%3E

Summarizing that discussion, we have a lot of issues/wishes. Some can be addressed as one-off and some need a unified reorganization of the runner comparison.

Basic corrections:

• Remove rows that impossible to not support (ParDo)
• Remove rows where "support" doesn't really make sense (Composite transforms)
• Deduplicate rows are actually the same model feature (all non-merging windowing / all merging windowing)
• Clearly separate rows that represent optimizations (Combine)
• Correct rows in the wrong place (Timers are actually a "what...?" row)
• Separate or remove rows have not been designed ([Meta]Data driven triggers, retractions)
• Rename rows with names that appear no where else (Timestamp control, which is called a TimestampCombiner in Java)
• Switch to a more distinct color scheme for full/partial support (currently just solid/faded colors)
• Switch to something clearer than "~" for partial support, versus ✘ and ✓ for none and full.
• Correct Gearpump support for merging windows (see BEAM-2759)
• Correct Spark support for non-merging and merging windows (see BEAM-2499)

Minor rewrites:

• Lump all the basic stuff (ParDo, GroupByKey, Read, Window) into one row
• Make sections as users see them, like "ParDo" / "side Inputs" not "What?" / "side inputs"
• Add rows for non-model things, like portability framework support, metrics backends, etc

Bigger rewrites:

• Add versioning to the comparison, as in BEAM-166
• Find a way to fit in a plain English summary of runner's support in Beam. It should come first, as it is what new users need before getting to details.
• Find a way to describe production readiness of runners and/or testimonials of who is using it in production.
• Have a place to compare non-model differences between runners

Changes requiring engineering efforts:

• Gather and add quantitative runner metrics, perhaps Nexmark results for mid-level, smaller benchmarks for measuring aspects of specific features, and larger end-to-end benchmarks to get an idea how it might actually perform on a use case
• Tighter coupling of the matrix portion of the comparison with tags on ValidatesRunner tests

If you care to address some aspect of this, please reach out and/or just file a subtask and address it.

Apache Beam [1] is a unified and portable programming model for data processing jobs. The Beam model [2, 3, 4] has rich mechanisms to process endless streams of events.

Complex Event Processing [5] lets you match patterns of events in streams to detect important patterns in data and react to them.

Some examples of uses of CEP are fraud detection for example by detecting unusual behavior (patterns of activity), e.g. network intrusion, suspicious banking transactions, etc. Also trend detection is another interesting use case in the context of sensors and IoT.

The goal of this issue is to implement an efficient pattern matching library inspired by [6] and existing libraries like Apache Flink CEP [7] using the Apache Beam Java SDK and the Beam style guides [8]. Because of the time constraints of GSoC we will probably try to cover first simple patterns of the ‘a followed by b followed by c’ kind, and then if there is still time try to cover more advanced ones e.g. optional, atLeastOne, oneOrMore, etc.

[1] https://beam.apache.org/
[2] https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
[3] https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102
[4] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43864.pdf
[5] https://en.wikipedia.org/wiki/Complex_event_processing
[6] https://people.cs.umass.edu/~yanlei/publications/sase-sigmod08.pdf
[7] https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html
[8] https://beam.apache.org/contribute/ptransform-style-guide/

Ray (https://ray.io) is a framework to develop distributed applications. There is a push to develop several libraries to support vario7us forms for AI/ML analytics with Ray. There is an opportunity to develop a Beam runner for Ray.

https://docs.google.com/document/u/1/d/1vt78s48Q0aBhaUCHrVrTUsProJSP8-EBqDDRGTPEr0Y/edit

We have the Beam Pydoc set up, and some functions have examples written into their documentaztion, however we do not run the examples that we express in Pydoc.

This work item consists in improving the Pydoc for Apache Beam to run examples, adding some examples, and reformatting any existing examples / existing Pydoc that needs to be better expressed for Beam.

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 Added} if you have questions, or comment here.

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 Added} 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.

Currently, Nemo doesn't have a spill mechanism. This makes executors prone to memory problems such as OOM(Out Of Memory) or GC when task data is large. For example, handling skewed shuffle data in Nemo results in OOM and executor failure, as all data has to be handled in-memory.

We need to spill in-memory data to secondary storage when there are not enough memory in executor.

In-memory caching and spilling are essential features in in-memory big data processing frameworks, and Nemo needs one.

• Identify and persist frequently used data and unpersist it when its usage ended
• Spill in-memory data to disk upon memory pressure

Please read the Observasibility proposal here first to know about the ultimate goal behind this issue.

If you are interested in this project and the objective described in the proposal, please leave comments on the corresponding Github issue below so we can further exchange information on the tasks that need to be done.

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/beamdubbo/pull/16763Contact Pablo Estrada on dev@beam.apache.org^{Image Removed} if you have questions, or comment here.issues/9886

• 目标
  首先，从宏观上、使用上掌握 Dubbo 及微服务治理相关概念；在此基础之上，设计一系列的 Demo 应用，基于这些应用设计出一系列微服务治理的 Tasks，每个 Task 涵盖一项或多项 Dubbo 的服务治理能力，通过详细描述的用例引导用户一步步的完成每一个 Task，进而帮助用户学习使用 Dubbo 能做到什么。

详情请在 https://github.com/apache/dubbo/issues/9887 讨论。

• 任务描述
  Dubbo 拥有丰富的治理规则，如服务发现、负载均衡、路由策略（标签路由、条件路由）等，但是这些治理规则的使用具有一定的难度，用户也很难直观的了解到其对应的使用场景。因此 Dubbo 期望有这样的一些场景化的用例能够体现 Dubbo 的治理能力，帮助用户将治理规则迁移到真实业务场景中使用。

这是一项相对比较有挑战性的任务，难度并不在编码本身，而在于对整个 Dubbo 及微服务体系要有比较总体的把握。如能顺利完成，对于参与者整体的视野提升将具有非常大的帮助。参与者可以导师一起协作完成。

• 参考：
  Istio 中 bookinfo 应用

We have the Beam Pydoc set up, and some functions have examples written into their documentaztion, however we do not run the examples that we express in Pydoc.

This work item consists in improving the Pydoc for Apache Beam to run examples, adding some examples, and reformatting any existing examples / existing Pydoc that needs to be better expressed for Beam.

Please read the detailed proposal of Dubbo Sidecar Mesh or Thin SDK here first to know about the ultimate goal behind this issue.

The details of this project will be posted on the following GitHub issue, please keep posted there.

https://github.com/apache/dubbo/issues/9885

Please read the detailed proposal of Dubbo Proxyless Mesh here first to know about the ultimate goal behind this issue.

The details of this project will be posted on the following GitHub issue, please keep posted there.

Ray (https://ray.io) is a framework to develop distributed applications. There is a push to develop several libraries to support vario7us forms for AI/ML analytics with Ray. There is an opportunity to develop a Beam runner for Ray.

https://docsgithub.google.com/documentapache/u/1/d/1vt78s48Q0aBhaUCHrVrTUsProJSP8-EBqDDRGTPEr0Y/editdubbo/issues/9884