Explore Projects

Up until version 1.16, [Istio](https://istio.io/) published [performance and scale testing results](https://istio.io/v1.16/docs/ops/deployment/performance-and-scalability/). These should be returned to service, and updated to support ambient mesh. Third-party benchmarking tools should be updated to support testing the performance of ambient mesh. - Expected Outcome: Performance testing pages are returned to istio.io, and include both sidecar and ambient mesh results.

When a large Prometheus is running in HA mode (i.e. 2 identical Prometheus scraping same targets) and it needs to be restarted (for upgrades, etc), there can be a temporary gap in queries when the second Prometheus is restarting. This is because the first Prometheus did not scrape any metrics when it was restarting (this is the gap), and when second Prometheus is restarting, only the first Prometheus is serving queries. To mitigate this, we want to start scraping targets as soon as Prometheus starts up, without waiting for it to complete the WAL replay and restore the old in-memory state. However, querying is still only enabled after WAL replay is over, but there won't be gaps in scraped data anymore. This project includes careful designing of low level technical challenges, including ensuring the correct handling of WAL records and seamlessly stitching together the new scraped data and the data restored from WAL without a lot of memory overhead. - Expected Outcome: - Design the correct handling of WAL records where the series information lines up between the old WAL and newly scraped data. - Design a low overhead method to stitch together the scraped data and the data restored from WAL. - Production ready PR with comprehensive test coverage. Ideally we will do the review iterations and merge the PR within this timeline.

Description: The Linkerd control plane includes controllers that are written in Rust. Enable users to dynamically profile the running application can aid significantly in debugging and diagnostics. Expected Outcome: In an upcoming release of Linkerd the policy controller would expose endpoints (leveraging [pprof](https://github.com/tikv/pprof-rs/blob/master/README.md) or another tool) for profiling controller resource consumption.

This Developer Relations project aims to accelerate KubeStellar UI adoption by building a vibrant community around this multi-cluster Kubernetes management interface. The mentee will establish KubeStellar's online presence across key platforms, create technical content showcasing multi-cluster management capabilities, produce regular demo livestreams, improve documentation for contributors, implement community feedback mechanisms, and represent the project at CNCF events. Expected Outcome: Established social media presence for KubeStellar, daily technical blog series, weekly/bi-weekly livestream demos, improved contributor documentation, active GitHub Discussions, community feedback system with analytics, and at least one CNCF talk submission.

The proposed project includes the following key activities: A systematic review of the applicability of fault-tolerant software patterns to Hyperledger Fabric chaincode as the potentially faulty software Creation of programming idioms for applying the applicable patterns to Hyperledger Fabric chaincode Prototyping "fault tolerance gadgets" (libraries) for easy application to chaincode The book "Patterns for Fault Tolerant Software" from R. Hanmer (Wiley, 2013) is a good reference of the patterns that the project will target. This is a research-focused project which is relatively light on programming. At the same time, a rather deep dive into the workings of Hyperledger Fabric is expected.

This project aims to ease the transition and implementation of Posits, an alternative numerical representation, for RISC-V systems. By creating a robust hardware abstraction layer (HAL), developers need not know if the target RISC-V platform has a hardware Posits implementation or requires a software implementation. This new POSIX-compliant C++ library (with ports planned eventually) will help make available the option to transition between IEEE Float / Doubles to Posits and should make the machine-specific selection and configuration seamless. The lack of such a HAL is a roadblock in Posit adoption and Posits represent a serious opportunity for free and open source silicon (FOSSi) systems. We will also update the existing posit implementations to the current standard and add consistent unit testing. Initial focus will be directed toward HPC support, where numerical computation efficiency may be best observed. Additionally, we will be conducting benchmarking studies to evaluate the performance of the HAL, identifying bottlenecks, and iterating on the design based on empirical data. The testing framework will also be part of the mentee's deliverables.

Thanos (https://thanos.io) has its own PromQL (Prometheus (https://prometheus.io) querying language) engine. The original PromQL engine recently added support for new aggregations. We are missing support for them in the Thanos PromQL engine (https://github.com/thanos-io/promql-engine). In this project you will implement support for limitk and limit_ratio. See issue (thanos-io/promql-engine#515). This will unblock users who need this functionality. The project is interesting because you will learn how query engines are implemented, about distributed query execution. Expected Outcome: limitk, limit_ratio are supported in the Thanos PromQL engine (local & distributed modes), tests are written for them

The kubeslice-cli repository currently lacks comprehensive unit and integration tests making it hard to test the changes. This project aims to implement a robust testing framework to ensure the reliability and stability of the CLI tool. The Mentee will write unit tests for existing functions & integration tests for the CLI commands & also set up a continuous integration pipeline to run these tests automatically on every commit and pull request. Expected Outcome: 1. A fully configured testing framework for kubeslice-cli with unit and integration tests covering all critical functionalities. 2. A CI/CD pipeline configuration (e.g., GitHub Actions) that automatically runs the tests on every pull request. 3. Documentation on how to run these tests & add new ones.

The Volcano community introduced JobFlow to address inter-job dependencies. Through the concepts of JobTemplate and JobFlow, users can declare and orchestrate multiple Volcano jobs, leveraging control flow primitives such as sequential, parallel, conditional, branching, and looping execution. JobFlow aims to facilitate the migration of AI, BigData, and HPC workloads to the cloud-native environment. The current JobFlow functionality requires further enhancements to meet more complex real-world scenarios. Ref: https://github.com/volcano-sh/volcano/tree/master/docs/design/jobflow. Expected Outcome: 1. Support modifying parameters of a JobTemplate when referenced in a JobFlow, for example, changing container image versions, adjusting resource limits, etc. 2. Implement a configurable retry mechanism for failed jobs within a JobFlow, for example, supporting exponential backoff retry policies, setting maximum retry attempts, etc. 3. Introduce richer control flow statements such as if, switch, and for statements, for example, conditional branching based on the status of upstream tasks, iterative execution of specific task sets, etc.

Implement default resource interpreters for RayCluster and RayJob workloads in Karmada. Expected Outcome: This includes interpreter development, validation, and comprehensive documentation on deploying and managing Ray workloads with Karmada. Present the integration and usage guide to the KubeRay community.

This program pairs one or more mentees with an experienced mentor to deliver an AOSP 12 emulator for 64-bit RISC-V. RISC-V International has setup Android SIG and released RISC-V Android github repo as https://github.com/riscv-android-src. Current RVI Android codebase is based on AOSP 10, while the latest AOSP is 12 now. We hope to catch up with latest AOSP 12 codebase, and as part of our plan, an emulator is required first as test and run environment. Deliverables (bullet list of components and the changes expected): - Add RISC-V target in the emulator. - Porting Ranchu virtual board to support RISC-V machine. - Corresponding unit tests implementation - Regression tests pass Note: upon work should be based on AOSP 12. 3. acceptance criteria Acceptance criteria (bullet list with measurable results defined): - Phase I: Virtual peripherals of emulator can work with RISC-V 64bit cores and pass unit tests. - Phase II: Emulator can boot-up with Linux plus basic rootfs w/o GUI for AOSP 12. - Phase III: Emulator can boot-up with Linux plus rootfs w/ GUI for AOSP 12. Note: due to AOSP 12 rootfs is still in developing, a AOSP 10 rootfs from Android SIG repo can be used instead to help verification, but the kernel version should be matched with AOSP 12.

Meshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems. This internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments. Expected Outcome: 1. A multitude of new relationships defined both intra and inter AWS services. 2. Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.

Enhance z/vm Prometheus exporter, as https://github.com/zvmexporter/zvm_exporter is pretty old and some stuffs like xcat is not maintained anymore, we propose to use Feilong as base to enhance Prometheus exporter and to provide more metrics to help ecosystem build up

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.

The llama nexus project is an API proxy to provide OpenAI-compatible and unified API endpoints for multiple downstream API servers, including LLamaEdge API servers running open-source LLMs. https://github.com/LlamaEdge/llama-nexus Currently, the Llama Nexus supports the stateless /chat/completions API endpoint for LLMs. We would like to expand this to support the /responses stateful API from OpenAI as well. https://platform.openai.com/docs/api-reference/responses https://platform.openai.com/docs/guides/responses-vs-chat-completions In particular, we aim to implement support for MCP Code interpreter Web search File search Browser use (optional) Expected Outcome: 1. New features for the Llama Nexus proxy server.

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