Skip to content

Commit

Permalink
LFX: Add Volcano project for Term 01 - 2025 March - May
Browse files Browse the repository at this point in the history
Signed-off-by: Monokaix <[email protected]>
  • Loading branch information
Monokaix committed Feb 2, 2025
1 parent 4528a3a commit d99425f
Showing 1 changed file with 41 additions and 4 deletions.
45 changes: 41 additions & 4 deletions programs/lfx-mentorship/2025/01-Mar-May/project_ideas.md
Original file line number Diff line number Diff line change
Expand Up @@ -120,7 +120,7 @@ Even though there are many integration tests, we wish to increase the coverage o

#### Jaeger: Upgrade Storage Backends to V2 Storage API

- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. A critical component of Jaeger is its storage backends, where traces captured by Jaeger are stored. With the release of Jaeger v2 last year we introduced a new, more efficient Storage API v2. However, the existing backend implementations in Jaeger are still using v1 API that is only wrapped in the v2 adapter, which prevents them from benefiting from the new capabilities such as batch writes and result streaming. The objective of this project is to upgrade some (or all) backend implementations to use the Storage API v2 natively. Please refer to the upstream issue for more details.
- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. A critical component of Jaeger is its storage backends, where traces captured by Jaeger are stored. With the release of Jaeger v2 last year we introduced a new, more efficient Storage API v2. However, the existing backend implementations in Jaeger are still using v1 API that is only wrapped in the v2 adapter, which prevents them from benefiting from the new capabilities such as batch writes and result streaming.The objective of this project is to upgrade some (or all) backend implementations to use the Storage API v2 natively. Please refer to the upstream issue for more details.
- Expected Outcome:
- Upgrade memory and Elasticsearch backends to use the Storage API v2 natively.
- Bonus: upgrade Cassandra and Badger backends to use the Storage API v2 natively.
Expand Down Expand Up @@ -150,7 +150,7 @@ Even though there are many integration tests, we wish to increase the coverage o
#### Karmada Self-Signed Certificate Content Standardization

- Description: In the existing [Karmada](https://github.com/karmada-io/karmada) architecture, each component should have its own unique certificates to ensure clear identity and security. Best practices dictate that each component's name be used as the Common Name (CN) in its certificate to facilitate identity differentiation. However, currently, all Karmada components share same identical certificate content, leading to confusion and potential security risks.
The objective of this project is to enhance the compliance of the Karmada certificate system by ensuring that each component possesses distinct certificates that reflect its identity. This will improve system security, reduce management complexity, and align with industry standards. This project aims to achieve the following standards:
The objective of this project is to enhance the compliance of the Karmada certificate system by ensuring that each component possesses distinct certificates that reflect its identity. This will improve system security, reduce management complexity, and align with industry standards. This project aims to achieve the following standards:
- Utilize a single CA certificate for the entire Karmada system.
- Issue individual server certificates for each server component, using the component name as the CN.
- Issue individual client certificates for each client component, using the component name as the CN, same client can use consistent certificate for different servers.
Expand Down Expand Up @@ -319,8 +319,7 @@ By implementing these enhancements, KubeStellar UI will evolve into a comprehens
- `lib/validator/validator_component.cpp`
- The visitor pattern are already setup.
- Recommended Skills:
- Since component model proposal separate their validation spec, one should able to
find requirements from https://github.com/WebAssembly/component-model/tree/main/design/mvp
- Since component model proposal separate their validation spec, one should able to find requirements from https://github.com/WebAssembly/component-model/tree/main/design/mvp
- Implements it in C++.
- Mentor(s):
- Lîm Tsú-thuàn (@dannypsnl, [email protected])
Expand Down Expand Up @@ -422,3 +421,41 @@ find requirements from https://github.com/WebAssembly/component-model/tree/main/
- Amy Super (@amy-super, [email protected])
- Andrej Kiripolsky (@AndrejKiri, [email protected])
* Upstream Issue: https://github.com/prometheus/prometheus/issues/15909

### Volcano

#### Volcano supports queue-level scheduling policies

- Description: Volcano supports unified scheduling of online and offline workloads, provides a wealth of scheduling plugins and algorithms, and can distinguish different tenants through queue distinction. The current scheduling policy is a global configuration, and all jobs in the queue use the same scheduling policy, but in actual scenarios, different tenants may need to use different scheduling policies due to different usage scenarios. Therefore, volcano needs to support setting and using different scheduling policies at the queue level instead of using a globally unified scheduling policy.
- Expected Outcome:
- A new field is added to the queue CRD, and users can set scheduling policies at the queue level.
- Volcano scheduler implements different scheduling policies based on the queue in which the job is located.
- Recommended Skills: Kubernetes, GO, Volcano
- Mentor(s):
- Xuzheng Chang(@Monokaix, [email protected])
- Zicong Chen(@JesseStutler, [email protected])
- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3992

#### Coordinate descheduler and Volcano to support resource defragmentation

- Description: Volcano community has provided Volcano descheduler to support descheduling. Currently, load-aware rescheduling is supported. Resource fragmentation is a problem that users are more concerned about. Volcano needs to provide a resource defragmentation strategy based on the existing descheduler, and needs to ensure that the evicted pods can be rescheduled successfully, which requires the cooperation of the rescheduler and the scheduler to solve resource fragmentation and maximize resource utilization.
- Expected Outcome:
- Implementing a resource defragmentation strategy based on Volcano descheduler.
- The Volcano descheduler works in conjunction with the Volcano scheduler to ensure that evicted pods can be re-scheduled successfully.
- Recommended Skills: Kubernetes, GO, Volcano
- Mentor(s):
- Xuzheng Chang(@Monokaix, [email protected])
- Zicong Chen(@JesseStutler, [email protected])
- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3948

#### Volcano dashboard feature enhancements

- Description: Volcano dashboard is a volcano resource front-end display tool. Currently, it only supports viewing resources, and the resources displayed are limited. It needs to support viewing more resources, and supports operations such as creation and deletion.
- Expected Outcome:
- Supports viewing resources other than volcano related resources.
- Supports add, delete, modify and query resources such as queues and volcano jobs.
- Recommended Skills: Kubernetes, React, Node, JS
- Mentor(s):
- Xuzheng Chang(@Monokaix, [email protected])
- Zicong Chen(@JesseStutler, [email protected])
- Upstream Issue: https://github.com/volcano-sh/dashboard/issues/11

0 comments on commit d99425f

Please sign in to comment.