Skip to content

Latest commit

 

History

History
847 lines (695 loc) · 64.4 KB

README.md

File metadata and controls

847 lines (695 loc) · 64.4 KB
Raw

Term 01 - 2024 March - May

Status: Ongoing

Mentorship duration - three months (12 weeks - full-time schedule)

Timeline

activity date
project proposals Monday Jan 8 - Wednesday Jan 24, 8:00 AM PDT
mentee applications open Monday Jan 29 - Tues Feb 13, 5:00 PM PDT
application review/admission decisions Wed Feb 14 - Tues Feb 27, 5:00 PM PDT
selection notifications Thurs Feb 29, 5:00 PM PDT (as selections are made on the platform)
Mentorship program begins with the initial work assignments Monday March 4 (Week 1)
Midterm mentee evaluations and first stipend payments Wednesday April 10 (Week 6)
Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals Wed May 22, 5:00 PM PST (Week 12)
Last day of term Friday May 31

Project instructions

Project maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2024/01-Mar-May/project_ideas.md, by January 24, 2024.

Application instructions

Mentee application instructions can be found on the Program Guidelines page.

Accepted projects

Antrea

East-west connectivity monitoring tool for Pod network

  • Description: As a K8s network plugin (CNI plugin), Antrea provides networking functions for K8s Pods. These Pods are located on different Nodes, which can be in different availability zones, or even different geos. We would like to provide as part of Antrea (built-in capability) a tool to monitor Pod connectivity across the cluster. This tool should be able to report the average network latency between any 2 Nodes in the cluster. The latency information could then be visualized using a heatmap representation in the Antrea web UI.
  • Expected Outcome: A new Antrea API which reports network health information and latency between K8s Nodes. If time allows, the Antrea web UI should also be extended so that latency information can be easily visualized through a heatmap.
  • Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, some basic networking knowledge (TCP/IP stack), frontend development experience (React, TypeScript) would be great but not required.
  • Mentor(s):
  • Upstream Issue: antrea-io/antrea#5514
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/12b695a0-e05c-46b9-a42d-c7e4709f0129

Ability to install / upgrade Antrea using the CLI

  • Description: Currently Antrea can be installed using a K8s YAML manifest or through the provided Helm chart. We believe there is value in providing a 3rd installation method, using the "antctl" CLI. The CLI installation / upgrade method would have the following advantages: a) more user-friendly, with support for command-line options to customize the installation, b) ability to run sanity checks on the K8s cluster before comitting to the installation, c) when upgrading, the CLI will ensure that Antrea components are upgraded in the optimal order, to minimize workload disruption.
  • Expected Outcome: A new command for antctl, the Antrea CLI, which will provide support for installation and upgrade.
  • Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, UX experience would be great but not required.
  • Mentor(s):
  • Upstream Issue: antrea-io/antrea#5896
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ae950bcf-d16b-4d26-aed0-702c1eedb507

Replace deprecated bincover with golang built-in coverage profiling tool

CNCF TAG Network

Mapping Kubernetes Resources: Identifying relationships between all standard and custom resources

  • Description: The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.
  • Expected Outcome:
    • YAML-formatted definition of one or more relationships per Kubernetes resource.
    • Documentation of each relationship - per component.
    • Development of new types of genealogies - new types of ways in which resources relate to one another and how these relationships might be visualized.
    • Verification of functional relationships
  • Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.
  • Mentor(s):
  • Upstream Issue: cncf/tag-network#35
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1e9ac76e-0434-45fc-8137-fc5698f29cd0

Chaos Mesh

Observability for StressChaos

Cilium

Governance Documentation

Cloud Native Buildpacks

Proof of concept for creating multi-arch images using buildkit

  • Description: A proof of concept to add buildkit support to pack in order to build multi-arch images. Pack is the reference implementation of a Cloud Native Buildpacks platform used to build application images from source code.
  • Expected Outcome: Multi-arch support has been one of the most requested features for Cloud Native Buildpacks, and this would allow end-users/developers to build multi-arch images with the pack cli.
  • Recommended Skills: Golang, Software development literacy, Familiarity building multi-arch containers with Docker and Buildkit. Familiarity with buildpacks will be helpful.
  • Mentor(s):
  • Upstream Issue: buildpacks/pack#1570
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2c5ced86-d23b-41f5-aec3-59730e29f092

CRI-O

Fully Automated CRI-O Releases

Flux

Conformance tests for AWS

  • Description: Flux has several integration points with hyper-scaler platforms e.g., AWS. In general it is tricky to test these satisfactorily, because it requires running in the platform and thereby incurring usage costs. GCP donate credits that are used to test there; and now the Flux project has been generously granted credits to use for testing in AWS, and we can create conformance tests for AWS specifically too.
  • Expected outcome: A suite of conformance tests for AWS integrations in Flux.
  • Recommended skills: AWS, Golang, GitHub Actions
  • Mentor: Stefan Prodan (@stefanprodan, stefan.prodan@gmail.com)
  • Upstream issue: fluxcd/flux2#4619
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/61486d56-9b28-42db-9e61-7a74b846cc15

Harbor

Harbor CLI

Harbor Satellite

Inspektor Gadget

Support for new types of eBPF programs

Testing framework for image-based gadgets

  • Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. Previously, Inspektor Gadget had a set of built-in gadgets. We are now moving to image-based gadgets where users can develop their own gadgets in eBPF and host them in OCI registries. But we don't have a test framework to help gadget authors to test their gadgets. This project will focus on implementing such a framework, possibly taking inspiration from the existing framework for built-in gadgets. The documentation for gadget authors should be updated. This project has the opportunity to expand beyond testing, to work on the gadget development experience over all, for example by creating a github template for gadget development.
  • Expected Outcome: Gadget authors can test their gadgets
  • Recommended Skills: Go, containers, Linux, testing
  • Mentor(s):
  • Upstream Issue: inspektor-gadget/inspektor-gadget#2046
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/65719d46-b71f-4778-a29b-3bb878d6ec70

Istio

Improve Test Coverage for Istio Ambient Mesh

Jaeger

Jaeger-V2 Storage Backends

Jaeger-V2 Observability

  • Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes.
  • Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1
  • Recommended Skills: Go, scripting, CI/CD
  • Mentor(s):
  • Upstream Issue: jaegertracing/jaeger#5084
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/077f3bec-e3d3-41f7-a527-655c62661f80

Jaeger-V2 Adaptive Sampling

  • Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Jaeger-v1 collector can serve sampling configuration to SDKs, and allows either static configuration (with hot reload) or adaptive sampling that continuously re-calculates the desired sampling probabilities. We need to enable all these capabilities in jaeger-v2.
  • Expected Outcome: Support adaptive sampling in jaeger-v2
  • Recommended Skills: Go, scripting, CI/CD
  • Mentor(s):
  • Upstream Issue: jaegertracing/jaeger#5084
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/00e78fef-e9a7-4e2c-bf29-e6099ac14b65

KCL

KCL Package Version Management

  • Description: The KCL package management tool primarily handles the management of third-party KCL packages for the KCL project, which includes tasks such as uploading and downloading these packages. When adding third-party packages to the KCL project, it is important to adhere to version management strategies. This involves carefully selecting and downloading the appropriate version of a package, especially when different versions of the same package are available.
  • Expected Outcome: Add version management to the KCL package management tool.
  • Recommended Skills: golang
  • Mentor(s):
  • Upstream Issue (URL): kcl-lang/kpm#246
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06b5baee-bdcd-4f5e-9a1a-454191445a01

KCL IDE Quick Fix

KCL IDE Update KCL Dependencies

Knative

Contributor Journey Research

  • Description: Getting new contributors onboarded into a complex project like Knative is a lot of work for both the new contributors and for the maintainers. This is compounded by the fact that many contributors don't stick around after the first few contributions. We would like to perform a research study into why some contributors stay while others leave the community after a bit, and determine where we can improve the contributor experience.
  • Expected Outcome: Create a report based off of user research detailing the current contributor journey within Knative and highlighting areas where that can be improved.
  • Recommended Skills: User Research, Communication
  • Mentor(s):
  • Upstream Issue: knative/ux#98
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/54afaf17-4dc9-4783-9641-a95b5a33af9e

Cross Namespace Event Links

  • Description: One of the most requested features in Knative Eventing over the past few years has been for triggers in different namespaces than brokers, and for subscriptions in different namespaces than channels. More information can be found in the upstream issue.
  • Expected Outcome: Knative Eventing Triggers and Subscriptions can reference Brokers or Channels in a namespace different from their own if the user possesses the necessary permissions to do so.
  • Recommended Skills: Go, Kubernetes
  • Mentor(s):
  • Upstream Issue: knative/eventing#7530
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/eba6b385-1293-4192-b2b4-7da3afb74476

Konveyor

Move2Kube: Exploratory approaches to artifact manipulation.

  • Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has built-in support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. As part of replatforming, we want to allow artifact manipulation at various levels to handle complex cases of replatforming flows. Example - while re-platforming from Netflix OSS spring boot feign client + eureka setup to Kubernetes (kubedns, kube-dns, services, ingress etc.) could need some artifact changes at different levels (code, architecture etc.).
  • Expected Outcome:
    • Identify various forms of artifact manipulation and explore approaches to support such manipulations.
  • Recommended Skills:
    • Golang
    • program analysis
  • Mentor(s):
  • Upstream Issue: konveyor/move2kube#1130
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f304369d-62eb-40e0-b52b-630276bf4000

Move2Kube: Simplify plugin architecture of m2k

  • Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. The tool has a powerful plugin based transformer architecture where developers can write their own custom transformer plugins to fulfil their re-platforming needs. However, concepts like path mappings etc could be simplified for better adoption. Example - writing a Move2Kube custom transformer needs developers to understand various concepts such as path mappings etc, can we reduce this learning overhead by simplifying the Move2Kube architecture?
  • Expected Outcome:
    • Come up with a simplified alternative design for plugin architecture for M2K
    • Migrate existing components to support the new design with backward compatibility (good to have).
  • Recommended Skills:
    • Golang
    • K8s
  • Mentor(s):
  • Upstream Issue: konveyor/move2kube#1131
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06986e04-9b64-411f-b7f4-35fec6a70d03

Move2Kube: Advanced Resources support and enhance other Move2Kube components

Kubearmor

Kubearmor Kata Container Support

Leverage OCI Hooks for Container Events

Dashboards for application behavior and KubeArmor state

KubeEdge

Auto Generate KubeEdge API Document

Image PrePull Feature Enhancement

  • Description: In the latest release, KubeEdge has implemented the ability for image pre pull. However, each task execution only supports images from the same image repository currently. We hope to enhance this feature to support capabilities like overriding images and secrets, complete end-to-end tests for this feature.
  • Expected Outcome: Support image and secret override in image pre pull feature. And E2e tests for this feature are added.
  • Recommended Skills: Golang, Kubernetes, KubeEdge
  • Mentor(s):
  • Upstream Issue: kubeedge/kubeedge#5341
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/267cdecd-8ab9-43ab-be0e-ccf70ae1c023

Keadm Tool Enhancement

Support latest version in keink and run demo on keink

KubeVela

Support versioning for definitions

  • Description: In KubeVela, X-Definitions provide the foundation for users to construct their applications. Currently we will automatically upgrade the definitions' version for our users, however, we still need the capability of explicit versioning in definitions. With this feature, our users can now manage the version easily for application upgrades and migrations.
  • Expected Outcome: Support expilict versioning in definitions to help application upgrades and migrations.
  • Recommended Skills: Go, Kubernetes
  • Mentor(s):
  • Upstream Issue: kubevela/kubevela#6435
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/acfbadbd-46c2-4647-a489-0db80c709740

Kyverno

Kyverno for Envoy Authorization

Kyverno VPA Recommender

Convert Kubernetes Best Practices Policies to CEL

Verify Multiple Image Attestations

K8sGPT

Enhance K8sGPT's analyzers Unit Test Coverage

LitmusChaos

Enhancement of litmusctl: Adding E2E Tests, CRUD Probes Commands, and Package Manager Availability

Enhancing Chaos Center: Implementing E2E Test Cases and Addressing CVE Issues

  • Description: This initiative focuses on augmenting the Chaos Center with comprehensive end-to-end (E2E) test cases, addressing the current gap in testing capabilities. The lack of extensive E2E tests has been a challenge, especially during release cycles. The project also targets fixing identified Common Vulnerabilities and Exposures (CVEs) in the Chaos Center, enhancing the overall security and reliability of the system.
  • Expected Outcome: The project aims to establish a robust E2E testing framework for the Chaos Center, significantly improving test coverage and reliability during releases. Additionally, it focuses on resolving all identified CVEs, thereby enhancing the system's security. These improvements are expected to result in more stable and secure releases, increasing user trust in the Chaos Center.
  • Recommended Skills: Golang, Kubernetes
  • Mentor(s):
  • Upstream Issue: litmuschaos/litmus#4406
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/828a5410-6e18-49a8-986e-0ad2dd5ecfa2

Enhancements in Chaos Center: Multiple Project Owners and Log Download API

  • Description: This project focuses on two major enhancements for the Chaos Center. First, it aims to enable the support for multiple project owners, a feature highly requested by users. This addition will allow for more collaborative and flexible project management within the Chaos Center. Second, the project will develop an API for downloading logs, providing users with easier access to log data. Furthermore, there's a need to update the API documentation to reflect these new changes and ensure that users have the latest information for seamless integration and usage.
  • Expected Outcome: The successful completion of this project will result in the Chaos Center supporting multiple project owners, fostering collaborative and efficient project management. The new log download API will enhance user experience by simplifying access to log data. Additionally, the updated API documentation will ensure that users have clear and current guidelines, supporting better utilization of the new features.
  • Recommended Skills: Golang, ReactJs
  • Mentor(s):
  • Upstream Issue: litmuschaos/litmus#4407
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0b526c4c-a8ed-4a81-a3f1-1c6ebf328977

Meshery

Meshery: UI Migration from MUI v4 to MUI v5 and NextjS 13

  • Description: Meshery's UI is powerful and utilizes frameworks like Next.js and Material-UI. However, it relies on outdated technology stacks, resulting in performance inefficiencies and increased maintenance overhead.
  • Expected Outcome: Migrate from MUI v4 to MUI v5 and fully utilize features of Nextjs v13. Migrate all class based components to function based component. Reduced code complexity and improved maintainability for long-term sustainability. Responsive and accessible UI that adapts to diverse devices and user needs.
  • Recommended Skills: ReactJs, NextJs, familiarity with Material UI, Redux and Redux Toolkit
  • Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Antonette Caldwell (nebula-aac, pullmana8@gmail.com)
  • Upstream Issue: meshery/meshery#6680
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9dc784dd-dbfb-4d60-81ce-4da95e0b48a0

Meshery: Expand CLI capabilities for registry management

  • Description: Meshery CLI is a powerful tool to manage all your cloud native resources, Meshery has internal capability called Registry to store and manage models, categories, component and relationship, presently Meshery’s v0.7 release allow users to view all this information from Mehery UI. We also need to expose Meshery’s registry capability through mesheryctl
  • Expected Outcome: Design mesheryctl subcommands and flags for registering, listing, retrieving, updating, and deleting models, components and relationships. Implement validation and error handling for user input and API responses. Integrate with relevant Meshery APIs to interact with the registry backend.
  • Recommended Skills: Golang, familiarity with Golang CLI framework Cobra
  • Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Uzair Shaikh (@MUzairS15 , muzair.shaikh810@gmail.com)
  • Upstream Issue: meshery/meshery#8176
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/441ebbbd-8084-4e4c-b072-bc78112502ef

Meshery: Expand integration with Artifact Hub

  • Description: While Meshery has made significant strides, its integration with Artifact Hub requires expansion and enhancement to maximize users experience. The goal is expand integration between Meshery and Artifact Hub which starts with making Meshery designs as a new Artifact Hub kind.
  • Expected Outcome: Definition and implementation of Meshery patterns as a distinct category within Artifact Hub. Design features to showcase Meshery's unique design patterns, enhancing visibility and accessibility. Collaborate with select publishers to integrate Meshery snapshots into Artifact Hub entries. Enhance user experience by providing visual representations of Meshery-related artifacts.
  • Recommended Skills: Familiarity with Helm charts and Artifact Hub, basic familiarity with Kubernetes
  • Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com)
  • Upstream Issue: meshery/meshery#9966
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/83c60c5f-3e79-4532-8ee6-1266e30d21e0

OpenKruise

Build simple Web-UI that can integration with exiting PaaS

  • Description: Currently, OpenKruise depends solely on the PaaS or CLI to listing OpenKruise workload display and operations. The lack of a general purpose Web-UI greatly hinder the adoption among developer users. This project is about to build a simple Web-UI that can list OpenKruise workload along with the native K8s workload, and support enhanced operation such as container restart or workload rollout. The Web-UI can be served directly as a dashboard , or as an example of OpenKruise integration in PaaS.
  • Expected Outcome:
    • simple Web-UI
    • integration of the Web-UI with existing PaaS such as KubeSphere
  • Mentor(s):
  • Recommended Skills: UX/UI, JavaScript, GoLang (a plus but not mandatory)
  • Upstream Issue: openkruise/kruise#1497
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4d241a4b-e568-4033-8f08-72b0cac60311

OpenTelemetry

One Logging Bridge per Language

  • Description: One of the goals set for the OpenTelemetry project in 2024 is to have at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively in their applications. While some languages have such a bridge already, some have the desire to implement at least one bridge but are lacking the engineering resources to do so. This internship starts by taking a look at the current state, marking which languages have a bridge already and which are lacking. The next step is to propose and implement at least one bridge for at least one language that doesn't have such a bridge yet.
  • Expected Outcome: At least one logging bridge is implemented for at least one language.
  • Recommended Skills: One (or more!) of the missing languages supported by OpenTelemetry
    • C++
    • Erlang
    • Go
    • JavaScript
    • PHP
    • Ruby
    • Swift
  • Mentor(s):
  • Upstream Issue: open-telemetry/community#1865
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d114b9d-015e-40f4-bdd7-9acbb836d84e

Prometheus

Client_golang CI/CD improvements

  • Description: Prometheus' client_golang is the Prometheus SDK for metrics instrumentation for Go applications. Client_golang promises full support for the 3 latests major Go versions, and for this task a lot of manual effort is executed by the community. Client_golang could receive several improvements around its CI/CD pipelines and automation:
    • Golang version upgrades requires autogenerating go files that Go Collector uses to collect Go runtime metrics.
    • Unit tests need to be run for the 3 latest Go versions, and running tests locally with different Go versions is hard at the moment. We can explore locally reproducible CI/CD.
    • The changelog of new releases still requires a lot of manual work, like going through commit history and hand-picking commits that need to be advertised. We want to explore automation around semantic conventional commits that allows Changelog/Release automation.
  • Recommended Skills: Go, Shell, CI/CD
  • Mentor(s):
  • Issue:
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c1ba948-5237-4bae-9dd2-ee9580b5a018

Service Mesh Performance

Service Mesh Performance: Adaptive Load Control with Nighthawk

  • Description: The adaptive load controller operates by iteratively running optimization routines to ascertain the maximum load a system can sustain. Typically, this maximum load is determined by the system's capacity to handle requests per second (rps). The metrics, such as CPU usage and latency, collected from the system under test (SUT) serve as constraints to assess whether the SUT can sustain the imposed load. However, it lacks comprehensive lifecycle management functionalities. This hinders its adoption and limits its potential for continuous performance monitoring and optimization.
  • Expected outcome: Implement mechanisms to trigger alerts and notifications based on performance thresholds or significant changes in key metrics. Integrate Nighthawk testing with existing CI/CD pipelines for automated performance validation and optimization as part of the development and deployment process.
  • Recommended Skills: Golang, familiarity with Service Mesh, grpc, docker, kubernetes
  • Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)
  • Upstream Issue: service-mesh-performance/service-mesh-performance#416
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/98b9a7d7-4dd4-45aa-96f9-145e058efcee

Service Mesh Performance: Distributed Load Testing with Nighthawk

  • Description: Many performance benchmarks are limited to single instance load generation (single pod load generator). This limits the amount of traffic that can be generated to the output of the single machine that the benchmark tool runs on in or out of a cluster. Overcoming this limitation would allow for more flexible and robust testing. Distributed load testing in parallel poses a challenge when merging results without losing the precision we need to gain insight into the high tail percentiles. Distributed load testing offers insight into system behaviors that arguably more accurately represent real-world behaviors of services under load as that load comes from any number of sources.
  • Expected Outcome: Implementation of distributed load generation in Nighthawk. Integration of Nighthawk with relevant service mesh performance testing scenarios. Capability to invoke Nighthawk for distributed load testing through APIs and command-line interfaces. Implementation of reporting mechanisms for distributed load testing results.
  • Recommended Skills: Golang, familiarity with HTTP/HTTPS performance testing tools, Service Mesh, grpc, familiarity with containerization technologies, like Docker would be helpful.
  • Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)
  • Upstream Issue: service-mesh-performance/service-mesh-performance#415
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bad94872-bd61-4960-915a-ea1945ddd15c

Vitess

Improve Unit Test Coverage

  • Description: Vitess is a scalable cloud-native database system for horizontal scaling of MySQL.The project is over 10 years old and there are parts of the code that don’t have very good unit test coverage. Revamping these code files and adding unit test coverage will help with the overall project health. Having strong unit testing is also useful in preventing introducing bugs when making code changes to these files. The task of the mentee would be to add said unit tests for the given code files. At the time of writing this proposal, the unit test coverage in Vitess stands at 47.3% of all lines of code.
  • Expected Outcome: Improved unit test coverage in Vitess.
  • Recommended Skills: Go, SQL, Unit testing
  • Mentor(s):
  • Issue: vitessio/vitess#14931
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/efed074b-3c68-4337-90ab-2a3f2d15c836

Volcano

Volcano supports multi-cluster AI workloads scheduling

  • Description: Volcano provides rich scheduling capabilities for AI workloads in the field of single cluster. In large model training scenarios, a single cluster cannot meet the computing power requirements of jobs, more and more users hope to submit jobs uniformly on multiple clusters for large model training, volcano needs to provide various scheduling capabilities, such as job management, gang scheduling, queue management, etc., and select the appropriate cluster for jobs to cope with the requirements of large model training.
  • Expected Outcome:
    • Implement a basic multi-clusters scheduling framework integrated with multi-clusters scheduler like Karmada or other multi-cluster orchestration.
    • Implement gang scheduling, fair scheduling in multi-cluster.
    • Implement queue management in multi-cluster.
  • Recommended Skills: Go, Kubernetes, Volcano
  • Mentor(s):
  • Upstream Issue: volcano-sh/volcano#3310
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/132a4971-6969-4ca6-a695-783ece3ac768

Volcano supports DRA integration

  • Description: DRA is a new generation device management mechanism for kubernetes. It introduces a new resource request API ResourceClaim, which requires kubelet, kube-controller-manager, scheduler, and third-party device management controllers to cooperate with each other to work. The kube-scheduler has implemented corresponding scheduling capabilities, Volcano also needs to implement the DRA scheduling plug-in to integrate the DRA function.
  • Expected Outcome:
    • A design document describing how to integrate DRA into volcano.
    • Implement DRA plugin in volcano.
  • Recommended Skills: Go, Kubernetes, Volcano
  • Mentor(s):
  • Upstream Issue: volcano-sh/volcano#3143
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3c2d290a-6e93-4185-88f5-56736365fe85

WasmEdge

Integrate MLX as a new WASI-NN backend

Integrate Intel Extension for Transformers as a new WASI-NN backend

Integrate whisper.cpp as a new WASI-NN backend

Integrate burn.rs as a new WASI-NN backend