Explore Projects

Cortex provides horizontally scalable, multi-tenant, long term storage for Prometheus metrics when used as a remote write destination, and a horizontally scalable, Prometheus-compatible query API.

Develop default resource interpreters for TrainJob and SparkApplication workloads in Karmada. Expected Outcome: The task involves implementing interpreter logic, validating scheduling/propagation, and documenting the process of running these workloads on Karmada. Share the practice and integration details with the Kubeflow and Spark communities.

Since jobflow is an important built-in orchestration engine for Volcano, it is still lack of user guidance. Please add more docs to demonstrate its installation, usage, tips and so on. - Expected Outcome: Add docs into volcano-sh/volcano/docs/user-guide and describe the usage of jobflow.

Headlamp currently fetches Kubernetes API data directly from the frontend, which can lead to performance bottlenecks and unnecessary API load. Introducing a caching layer in the headlamp-server backend will reduce API calls, improve response times, and enable more efficient data handling. This enhancement will also allow for improved pagination—fetching only the data needed for the current view—and enable backend-powered search functionality, reducing the need for the frontend to download large datasets. Expected Outcome: 1. A backend caching layer for Kubernetes API responses, scoped per user context to ensure data isolation and security. 2. A new pagination API that allows the frontend to request only the currently visible page of data. 3. A search API that queries the cached data, enabling fast and efficient search without full data downloads. 4. Documentation and possibly a demo video explaining the architecture and usage of the new caching, pagination, and search features.

This project focuses on improving localization workflows in Kubernetes SIG Docs by strengthening visibility, prioritization, and traceability across English and localized documentation. The enhanced workflows will benefit to reducing review burden and coordination costs that arise in environments where upstream content changes and subsequent localization efforts occur asynchronously. The project also explores practical approaches to achieving measurable productivity gains by adopting AI-assisted tools within established human workflows. Mentees work with mentors in SIG Docs localization to improve existing localization review and coordination processes, such as label-based coordination and review signals implemented through Prow/CI. The project focuses on the following core areas: improving traceability between frequently changing English content and localized documentation, continuously tracking and notifying review priorities for translation updates, and maintaining visibility into localization coverage and prioritization based on document importance. All outcomes are designed to integrate naturally into existing SIG Docs GitHub workflows and practices while preserving and supporting human-led review and decision-making. - Expected Outcome: - Reusable Prow/CI automation prototypes - Extensible architecture - Best practices documentation

The current validator of component model inside of WasmEdge only check nested module and ensure VM can run the nested modules without problem, but the validations from component model are mostly skipped. Expected Outcome: 1. One should create a workable (merged into upstream) implementation of validator by working on 2. include/validator/validator_component.h 3. lib/validator/validator_component.cpp 4. 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

Reduce adoption friction by building integrations between KubeStellar and popular Kubernetes ecosystem tools. The mentee will survey early users to identify integration priorities, design integration architectures, develop working integrations with tools like GitOps platforms, Terraform, CI/CD systems, or monitoring solutions, create comprehensive documentation and examples, and validate integrations with real users. This program emphasizes software development, API integration, understanding ecosystem tools, and creating seamless user experiences. Expected Outcome: 2 production-ready integrations with popular Kubernetes tools, Integration documentation with clear setup guides for each, 2 demo videos demonstrating integration value and setup, Sample implementations and templates for common scenarios, 3 users actively adopting each integration, Submissions to relevant tool marketplaces where applicable, Integration maintenance guide for ongoing support, User feedback on integration quality and usefulness, User engagement: 6 GitHub issues filed by integration users, 4 PRs or PR reviews contributed by integration users

LitmusChaos is a Kubernetes native chaos engineering framework that helps SREs & developers find weaknesses in their deployments, with the chaos intent being defined via custom resources. The Litmus portal is a dashboard focused on simplifying the chaos-engineering experience for users and allows the execution of complex "chaos workflows" that comprise one or more chaos experiments. This portal dashboard needs to be improved to hold more observability information, primarily in the form of an event log & alerts to help users gather important information about the state of the chaos experiments & cluster in general.

Policy-based control for cloud native environments.

"Overview: The UETRV PicoCore project aims to enhance the capabilities of the existing UETRV_Pcore RISC-V core, making it a versatile and feature-rich open-source microcontroller. The core is RV32IMA Linux-compatible and Privilege Architecture 1.10 compliant, and we envision integrating essential extensions such as bitmanip, floating point, debug, trace, and GPIO peripherals. This initiative aligns with the broader goal of providing a comprehensive RISC-V MCU solution that is accessible to the open-source community. Tasks: Bitmanip Extension Integration: The Bitmanip extension offers advanced bitwise manipulation instructions. The task involves integrating this extension into the existing UETRV_Pcore, optimizing its usage, and ensuring compatibility with existing codebases. Floating Point Extension Integration: Incorporating the Floating Point extension will enable hardware-accelerated floating-point computations. This task involves integrating the extension into the core, optimizing performance, and ensuring compliance with the RISC-V standard. Debug, Trace, and GPIO Peripherals: Enhancing the microcontroller's capabilities, this task involves integrating debug and trace functionalities for improved development and debugging. Additionally, GPIO peripherals will be integrated to facilitate easy interfacing with external devices.

The award-winning SERV (https://github.com/olofk/serv) is the world's smallest RISC-V CPU and is suitable for deeply embedded applications where chip area is at a premium. In a real system however, not only the CPU sets the system size and the smaller the CPU, the more important to also minimize the memory size. Adding support for the C ISA extension (compressed instructions) to SERV would enable RISC-V to reach even more use-cases on the deeply embedded side. SERV is an open source bit-serial RISC-V implementation written in Verilog with an emphasis on resource efficiency. The addition of the C ISA extension is expected to consist of changes to the instructions fetcher, an extra optional decoder stage for converting the compressed instructions into their non-compressed equivalents as well as other changes related to the PC not necessarily being word-aligned. On the infrastructure side, the relevant test suites (riscv-formal and riscv-compliance) are expected to pass and it should run the Zephyr operation OS with compressed instructions enabled. The SERV FuseSoC core description file should also be updated to allow users to conditionally select the C ISA extension at compile-time for simulation and FPGA/ASIC targets.

Prometheus and OpenTelemetry are commonly deployed together, yet many users struggle to understand how the two systems interoperate — especially around concepts such as resource attributes, label mapping, attribute promotion, and recommended integration patterns. Prior UX research (https://opentelemetry.io/blog/2025/ux-research-prometheus-otel/) identified documentation gaps as a primary source of confusion, and ongoing community discussions (https://opentelemetry.io/blog/2026/sl)continue to surface similar questions. While both projects provide extensive documentation, guidance is often fragmented, highly technical, or lacks practical end-to-end explanations for real-world usage. This mentorship focuses on improving the clarity, usability, and consistency of documentation that explains how Prometheus and OpenTelemetry work together. The mentee will analyze existing documentation across both projects, identify high-impact gaps or friction points, and collaborate with mentors to design and deliver meaningful documentation improvements upstream. The project is intentionally exploratory and iterative. Part of the mentorship is learning how to evaluate documentation quality, prioritize improvements, and define ways to measure the impact of documentation changes made during the program. Expected Outcome: 1. Review and audit existing Prometheus and OpenTelemetry documentation related to interoperability.....

Leading Open Source Container Attached Storage, built using Cloud Native Architecture, simplifies running Stateful Applications on Kubernetes.

The component-model proposal merges and supersedes the Module Linking and Interface Types proposals. With this feature, WasmEdge can execute multiple modules wasm with Module Linking and and more flexible types with Interface Type.

This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. - Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically: 1. Builds the required Kubespray OS images used in CI for tested distributions. 2. Pushes these built images to the appropriate registry. 3. Cleans up old or no longer needed images but retains those required for supported release branches.

Vitess is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included. Expected Outcome: The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers. Once a decision is made, the mentee is expected to implement the decisions from the maintainer team. The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post. The mentee is expected to review the Getting Started docs (https://vitess.io/docs/20.0/get-started/) on the Vitess website and enhance them to improve the onboarding experience. The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.

With the rapid growth of the RISC-V ecosystem, an increasing number of eage computing devices and IoT boards are adopting RISC-V. In very early versions of KubeEgde, we briefly verified compatibility with RISC-V. However, this has not been continuously validated in recent releases. As the codebase has evolved significantly, we need to re-establish and solidify support for this architecture to ensure KubeEdge can run seamlessly on the next generation of open hardware. Expected Outcome: - Deploy and run KubeEdge on actual RISC-V devices. Fix identified issues and submit PRs. - Generate official release assets (binaries) and multi-arch images for RISC-V. - Output a guide as a blog or docs about how to run KubeEdge on RISC-V to the kubeedge/website. - (optional) Explore how to add a basic verification step for RISC-V in KubeEdge GitHub Actions CI.

All In is a community dedicated to advancing diversity, equity, and inclusion within open source. All In for Students is a paid, 12-month program for select college students from underrepresented backgrounds. During the program, students will receive professional development training, open source education, a structured 12-week open source project, and ultimately have the opportunity to join one of our corporate partners for a summer internship experience.

Envoy is an open source edge and service proxy, designed for cloud-native applications.

FINOS (FinTech Open Source Foundation - part of the Linux Foundation) is looking for a summer marketing intern to assist with: - Marketing research (members, projects, BD) - Social media (research, operations) - Content for website (research, operations) - Podcast production (research, operations)

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. Convolution is the core operation of deep learning models and computer vision applications. MLIR supports various convolution operations. Our project is to vectorize them for the RISC-V backend. There are several methods to implement convolution vectorization, such as optimizing nested loops, implementing vectorization algorithm, converting to GEMM, etc. This project needs to choose a vectorization method and implement a conversion pass for the convolution operations. As for the vector semantic support, MLIR has the “Vector” dialect for the general vector abstraction, and it also allows the backend-specific vector dialect, such as the “x86vector” dialect, “arm_neon” dialect, and “arm_neon” dialect. Like these dialects, the project also needs to propose an “RVV” dialect and work with existing dialects and tools. Deliverables: - An MLIR “RVV” Dialect. (Operations in the dialect can support the convolution vectorization) - A conversion pass to vectorize convolution operations in “Linalg” dialect with “RVV” dialect enabled. - A conversion pass to lower the operations in “RVV” dialect to “LLVM IR” dialect. - Unit tests for “RVV” dialect and conversion passes.

The Software Package Data Exchange (SPDX) is an open source standard for communicating software bills of material information (including components, licenses, copyrights and security references). To support SPDX, an online tool has been developed which provides an easy all-in-one website to upload and parse SPDX documents for validation, comparison and conversion and search SPDX license list. This project will provide enhancements and support for the online tools including: - More automated and high-quality deployment for software updates - Removing some of the dependencies on a Python Java Bridge by moving features like license matching over to a native Python implementation - Improving performance and quality of the online tools implementation

Hyperledger Cactus is a blockchain decentralised integration tool designed to allow users to securely integrate different blockchains started by companies Fujitsu and Accenture. Cactus has pluggable architecture which makes easy to integrate various blockchain by creating plugin, currently plugins for Fabric, Besu, Quorum are implemented. Cactus allows to transfer not only assets but also data between multiple blockchains. On the other hand Iroha (version 1.x) is great with asset management, and has functionality to store data, which makes those two projects a perfect fit! With this internship we will not only allow the interoperability between different blockchains but also create a system of Iroha networks that will also demonstrate the integration in examples easy to run by everybody. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and Cactus, 3) work in true spirit of open-source, communicating with both Iroha and Cactus community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5)following rules and standards of open-source projects created by hyperledger Expected Outcome 1) Documented, ready-to-use integration of Iroha and Cactus, 2) Documented example of integration between multiple (two and more) iroha's networks with Cactus, 3)Documented example of integration between Fabric and Iroha