Explore Projects

OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. Currently, OpenELB supports the BGP protocol. However, the BGP policy is not fully supported in OpenELB. Therefore, based on the BGP protocol, OpenELB is supposed to support the BGP policy to enable leveraging the GoBGP policy feature for controlling the route advertisement.

Harbor is a widely adopted container registry, and its initial CLI has been developed by LFX mentees. The goal is to extend this CLI by implementing additional functionalities and workflows that are currently only available in the Web UI. The CLI should be useful for Harbor administrators and users, especially to manage workflows within CI/CD pipelines. We seek a Golang-experienced mentee to enhance the CLI independently. Expected Outcome: 1. Extend the Harbor CLI to include essential commands not yet implemented. 2. Add new features to improve Harbor management via the CLI, enabling robust workflows in CI/CD environments.

In the scheduling progress, the karmada-scheduler makes decisions as per a bunch of factors, one of the factors is the resource details of the cluster. We don't want to collect and store each node's resources in detail(That's a burden for Karmada to maintain the information), but we want to build a resource model for each cluster.

On a periodic basis, the CNCF would like to present a public challenge to those that are interested in participating (e.g. “Challenge: Distributed Tracing with Jaeger”). Your mission in this internship is technical content creation of said challenges through use of markdown, Meshery, and any number of other CNCF projects. Challenges will be created using the Meshery Playground and published (in what is potentially the CNCF Hub). They will be similar too, but slightly different from these [example tutorials](https://docs.meshery.io/guides/tutorials/). Understand that your challenges will be promoted through CNCF channels, reviewed by various project maintainers, and that each challenger (participant) will receive a certain number of points, depending upon whether or not they successfully complete the challenges that you create and in what timeframe they complete those challenges (the faster, the more points). Your challenges will need to vary in level of difficulty. Expected Outcome: - 5+ new challenges published - Challenges can contain more than one objective. Points are earned for each objective completed. - Bonus: Extend one or more of Meshery’s Learning Paths.

Creating applications for the Zowe Virtual Desktop requires a significant amount of programming that can be automated. The purpose of this project is to expand on an existing prototype to make stub application generation a breeze for new comers and future exploiters wanting to experiment with Zowe.

This project is about updating and optimizing the [protocol buffers](https://developers.google.com/protocol-buffers) implementation used for communication throughout the Thanos project. Thanos relies heavily on gRPC and protocol buffers for communication between its many components, and now with the release of the [new Golang API for protocol buffers](https://blog.golang.org/protobuf-apiv2) and the deprecation of the old API, Thanos should be updated to benefit from the improvements in the ecosystem. As part of this project, the protocol buffers generator used in Thanos will be migrated to one that supports the new API and brings other improvements, such as reducing memory allocations. This project will help make Thanos faster and ensure that we stay up to date with the latest libraries.

Open source projects should not be hard coded to a particular Database. Armada currently only allows users to use Postgres. This project is to build interfaces around our connections to Postgres so we can allow other databases. Expected outcomes: - A interface is created that allows Armada to interact with any SQL database without exposing implementation details of postgres - increase Test coverage

Karpenter is a dynamic Kubernetes node autoscaler that provisions compute resources in response to real-time workload demands. While Karpenter is powerful, it lacks a native UI for visualizing its autoscaling behavior and managing its custom resources. This plugin will integrate Karpenter-specific insights into Headlamp, leveraging Headlamp’s existing CRD support to provide a focused, user-friendly interface for understanding and managing Karpenter’s decisions. Expected Outcome: A Headlamp plugin that provides: 1. Show Karpenter Provisioners, NodePools, and NodeClasses, including their constraints and current status. 2. Real-time display of scaling decisions, such as which pods triggered provisioning and why. 3. A dashboard for pending pods with unmet scheduling requirements, highlighting why they couldn’t be scheduled. 4. Integration with Kubernetes events and Karpenter metrics to show provisioning latency, node lifecycle events, and cost efficiency. 5. A configuration editor for Karpenter Custom Resource Definitions(CRDs) using Headlamp’s existing CRD facilities. 6. Documentation and possibly a demo video or blog post.

Currently, Jaeger v1 has an official Helm chart (https://github.com/jaegertracing/helm-charts), but there isn't one yet for Jaeger v2. The goal of this project is to develop a comprehensive Helm chart for Jaeger v2 that allows for easy deployment and management of Jaeger v2 components in Kubernetes environments. This chart should provide flexibility in configuration, support various deployment scenarios, and integrate well with the new architecture of Jaeger v2. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5767). Expected Outcome: By the end of this project, we aim to have a production-ready Helm chart for Jaeger v2 that is: - Fully functional and tested on the current version of Kubernetes - Well-documented with clear usage instructions and examples - Flexible enough to support a wide range of deployment scenarios - Ready for submission to the official Jaeger Helm chart repository

The objective of this project is to perform a performance and benchmarking analysis of BESU, a Hyperledger project, in private networks (QBFT, IBFT, CLIQUE) using Hyperledger Caliper. This project aims to identify the strengths and weaknesses of BESU in terms of maximum transactions per second, latency, computation power, hard disk space, etc. Additionally, this project aims to add support for more complex and well-known workloads like ERC20, ERC721 in Caliper, which are used by general Ethereum users. This project will provide valuable insights into the performance of BESU and will help developers optimise it for better performance. Learning Objectives Through this project, the mentee will: - Develop skills in benchmarking and performance analysis of blockchain networks - Gain experience in working with Hyperledger Besu and Hyperledger Caliper - Learn to add support for new workloads in Caliper - Improve their programming skills by working on a real-world open-source project - Learn to write technical research reports and documentation. Expected Outcome The expected deliverables of this project are: - A detailed report on the performance of BESU in private networks (QBFT, IBFT, CLIQUE) - A set of benchmarks for BESU in private network with different configurations - Support for ERC20, ERC721, etc workloads in Hyperledger Caliper - Documentation on how to use the benchmarking tool and the new workloads.

Implement rust wrapper around aries-vcx to enable consuming the library in mobile setting using modern FFI approach using uniffi library. Additionally implement aries mediator client to unlock full mobile support. Learning Objectives - Learn about self sovereign identity and Aries protocols - Learn Rust language - Learn basics of Kotlin language, basics of Android development - Learn Github Actions and CI process in general - Learn about FFI (Foreign Function Interface) by using uniffi library Expected Outcome - uniffi_aries_vcx rust crate which generate mobile bindings for aries-vcx library - implement mediator client with aries message pick-up protocol support - simple android demo application which can be run in simulator - CI job to build Kotlin and iOS bindings, CI job to test the wrapper

As a Kubernetes (K8s) network plugin (CNI plugin), Antrea provides networking functions for K8s Pods and includes various troubleshooting tools for cluster administrators and application developers to diagnose networking issues. The PacketCapture feature (https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) was introduced recently (Antrea v2.2) and allows capturing network traffic for specific endpoints using predefined filters similar to those supported by libpcap/tcpdump. Users can initiate a packet capture through a Kubernetes Custom Resource Definition (CRD) or a CLI command. The Antrea control plane then generates and injects the corresponding BPF program, and the captured packets can be exported as a pcap file. In the last iteration of the LFX mentorship program, we added support for L4 filters (TCP flags, ICMP type & code) to the PacketCapture API, to enable Antrea users to target network traffic more precisely. We would like to keep improving the PacketCapture feature with 1) IPv6 support, 2) more flexibility when providing the source and destination, 3) the ability to specify the capture point for traffic (source or destination Pod). Expected Outcome: Extend the API definition for the PacketCapture CRD, and implement the new API functionality by generating the correct BPF instructions. The antctl CLI command for PacketCapture should be updated as needed to accomodate for the API changes.

Cluster API Provider AWS (CAPA) enables the creation of Kubernetes clusters in AWS with Cluster API. CAPA allows you create EKS and non-EKS based Kubernetes clusters. When creating a non-EKS cluster we must use AMIs for the nodes in the cluster. The project publishes some AMIs for non-production use. However, the process for publishing the AMIs needs improvment. Firstly we want to fully automate the publication of new AMIs when there is a new Kubernetes version available. Secondly, we need to implement the "AMI Publication Policy" for the project which will involve automated house keeping of AMIs. And thirdly we want to add back support for base operating systems that where temporarily dropped. - Expected Outcome: Automated AMI publication and deletion inline with the projects policy. Support for additional operating systems.

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 autoregressive decoding mode of LLM determines that LLM can only be decoded serially, which limits its inference speed. Speculative decoding technique can be used to decode LLM in parallel with the help of draft model, so as to improve the inference speed of LLM without loss of accuracy. However, the speculative decoding technology of LLM does not consider the application in the cloud-edge distributed environment. This project aims to implement cloud-edge collaborative speculative decoding based on KubeEdge-Ianvs, an open source cloud-edge collaborative distributed machine learning platform, so as to further improve the LLM inference speed in cloud-edge environment. Expected Outcome: - Implement an example of cloud-edge collaborative speculative decoding based on KubeEdge-Ianvs platform. - (Optional) Propose a more efficient cloud-edge collaborative speculative decoding algorithm.

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