-
Notifications
You must be signed in to change notification settings - Fork 634
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
LFX: Add Volcano project for Term 01 - 2025 March - May
Signed-off-by: Monokaix <[email protected]>
- Loading branch information
Showing
1 changed file
with
41 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
|
@@ -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. | ||
|
@@ -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]) | ||
|
@@ -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 |