Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
In an effort to better the user experience, the CNCF Landscape is actively seeking ways to improve and enhance its features. - The aim is for the mentee to carry out a User Research to validate existing user personas, gain a deeper understanding of user needs, and conduct a thorough heuristic evaluation to gain insights into user experiences. Using the results, the mentee will establish a solid foundation to start an iterative process of ideation, prototyping, and testing possible solutions. The ultimate goal is to initiate a continuous cycle of improvement and further development of features that enhance the user experience of the CNCF Landscape. Recommended skills: Design Thinking, UX research methodology. In this stage of the project, we are seeking candidates with a background and/or training in user research. Supporting materials, such as the following recommended deliverables, that demonstrate your understanding and experience in this area are ideal: 1. Proto-Personas 2. Validated Personas with Supporting Findings 3. Brief Explanation of the Difference between Proto-Personas and Validated Personas 4. List of UX Research Techniques for Kickstarting the Discovery of Landscape Users 5. Figma and Visual Design are a plus.
CoreDNS (https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters to make easy infrastructure management. One such case is certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in https://github.com/coredns/coredns/issues/3460.
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.
his project aims to build an E2E Web dashboard that will display the CI/CD pipeline details of [scheduled](https://litmuschaos.github.io/litmus-e2e/generic-pipeline/pipeline-runs/pod-level-run.html) and [manual](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) runs. It should contain all the litmus backend and portal pipelines and can be easily switched or add more pipelines. Currently, [these](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) are the pipeline present in the e2e.
<p>[Metal3](https://metal3.io/) is a Kubernetes-native project for managing bare metal hosts using Kubernetes APIs and operators. This project builds a Headlamp plugin that adds a Metal3 section to Headlamp, surfacing Metal3 CRDs so operators can view and manage bare metal hosts, provisioning states, and infrastructure resources from the Headlamp UI. The plugin follows Headlamp UX patterns with list and detail views, links between related resources, and optional metrics embedding.</p><p><br></p><p>Expected Outcome:</p><p> - Plugin exposes key Metal3 CRDs: BareMetalHost, Provisioning, HardwareData, and related resources.</p><p> - List views, with summary columns (name, namespace, status, provisioning state, power state, hardware profile).</p><p> - Detail pages, showing config, status conditions, hardware data, sub-resources (BMC info, NICs, disks), and basic actions (power on/off, reprovision).</p><p> - Relational navigation, cluster → hosts; host → provisioning state and hardware data.</p><p> - Consistent Headlamp UX, icons, tables, detail layouts, Map view enhancements.</p><p> - Structured config display (collapsible sections/YAML toggle), humanized statuses, validated forms for mutating actions.</p><p> - README with prerequisites and limitations; blog post demoing usage.</p><p><br></p>
his project aims to develop AI/ML models for NFV-usecases. Any two of the following three problems can be considered. VNF/CNF resource/performance/failure prediction NFV log analysis with NLP Synthetic monitoring and logging data generation using GANs Learning Objectives ML Techniques: Deep_learning. ML model development AI/ML for Telco Usecases. Interested Interns: DO NOT apply through this platform. Due to a bug, please go to https://wiki.lfnetworking.org/x/EasZB. Read the complete description. When you a ready to apply send your application documents to your Mentor(s) and mentorship@lfnetworking.org
Currently, in OpenYurt, the core component YurtHub—which acts as a transparent proxy between edge node system components (e.g., kubelet, CNI, CoreDNS, kube-proxy) and the Kubernetes API server—is deployed as a systemd service on each edge node. The installation is performed exclusively via the community-provided tool YurtAdm during node joining. This approach imposes a significant limitation: users must use YurtAdm to onboard nodes, making it impossible to install YurtHub on existing Kubernetes nodes that were not initially provisioned with YurtAdm. To improve flexibility and user experience, the community aims to support a label-driven, declarative installation mechanism: 1. When a specific label (e.g., openyurt.io/is-edge-worker=true) is added to a node, YurtHub should be automatically installed and started on that node. 2. Conversely, when the label is removed, YurtHub should be gracefully uninstalled and its resources cleaned up. This enhancement will enable seamless integration of OpenYurt into existing Kubernetes clusters without requiring re-onboarding of nodes. Expected Outcome: 1. Design and implement a controller/operator that watches for node labels and triggers YurtHub lifecycle operations. 2. Develop an installation/uninstallation mechanism that: a. Installs YurtHub as a systemd service. b. Ensures idempotency and handles failures gracefully. c. Cleans up all YurtHub-related files, configurations, and services
<p>Today most Koordinator scheduler plugins (DeviceShare, NodeNUMAResource, Reservation, etc.) keep their own private cache per scheduling framework/profile, so configuring multiple profiles in a single `KubeSchedulerConfiguration` produces duplicated plugin caches even though the upstream `SchedulerCache` and `PodNominator` are singletons per scheduler instance. This duplication wastes memory, desynchronizes state across profiles, and exposes correctness bugs: in `RunFilterPluginsWithNominatedPods`, `AddPod` is invoked for pods that are still in scheduling and are therefore missing from `nodeDeviceCache`'s used map, which causes DeviceShare and NodeNUMAResource to fail to reserve resources for high-priority pods in RDMA / VF / NV-Switch scenarios. This project will introduce a unified plugin-level Cache and Nominator abstraction that is shared across all profiles in the same scheduler instance, correctly integrates with `Reserve` / `UnReserve` lifecycle hooks, and fixes the `AddPod` / `RemovePod` handling for high-priority device and NUMA workloads.</p><p><br></p><p>Expected Outcome:</p><p> - A shared plugin-level `Cache` and `Nominator` framework exposed to Koordinator scheduler plugins, with a lifecycle tied to the scheduler instance rather than individual profiles</p><p> - Migration of DeviceShare, NodeNUMAResource, and Reservation plugin caches to the shared implementation, removing per-profile duplication</p><p> - Correct `AddPod` / `RemovePod` handling via reused `Reserve` logic that records assignment placements in the nominator, cleared symmetrically on `Reserve` / `UnReserve`</p><p> - Regression and stress tests covering multi-profile scheduling, preemption with nominated pods, and high-priority RDMA / VF / NV-Switch device assignment</p><p> - Developer documentation describing the shared Cache / Nominator API and migration guidance for other plugins</p><p><br></p>
<p>Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers that provides routing, policy enforcement, and tool federation. As the agentic ecosystem grows, we're looking to extend the gateway's capabilities beyond MCP to support other agentic protocols. The A2A (Agent-to-Agent) protocol is an emerging standard for inter-agent communication with capabilities like long-running tasks, streaming, and agent discovery via agent cards. This project will investigate how A2A support can be added to the gateway alongside MCP, then build a proof-of-concept demonstrating federated agent discovery and A2A request routing through the gateway. The mentee will work closely with mentors throughout — collaborating on the design doc, pairing on implementation decisions, and spiking on specific pieces as needed to validate assumptions early. They will also engage with the broader Kuadrant community through PR reviews, design discussions, and community calls.</p><p>- Expected Outcome:</p><p> - Analysis of the A2A protocol with a gap assessment comparing A2A and MCP traffic patterns (request/response vs long-running tasks, push notifications, multi-modal artifacts)</p><p> - Design document covering A2A routing through ext_proc, federated agent card serving in the broker, session handling implications, and CRD design</p><p> - Federated agent card endpoint in the broker that aggregates upstream A2A agent cards</p><p> - A2A request routing through the Envoy ext_proc path, with appropriate header handling and policy enforcement</p><p> - CRD design (new resource or MCPServerRegistration extension) for registering A2A agents with the gateway controller</p><p> - E2E tests demonstrating A2A agent discovery and task execution through the gateway</p><p><br></p>
Prometheus recently [announced the second version of it's remote-write protocol](https://prometheus.io/docs/specs/remote_write_spec_2_0/), with support for new features on top of performance and cost savings. The work to be done is contribute support for this new protocol in the OpenTelemtry-Collector-Contrib repository, more specifically to the `prometheusremotewriteexporter` component. Expected Outcome: `prometheusremotewriteexporter` component with support for PRW v2.
With the latest advancements in PipeCD, the plugin architecture for piped has been successfully established (ref: PipeCD plugin-arch blog) (https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/), opening the door for community-driven plugin development. While GitOps traditionally focuses on managing workload states, what about database states? Tools like sqldef (https://github.com/sqldef/sqldef) can be incredibly helpful, especially when adopting a GitOps approach. Expected Outcome: 1. SQL plugin for PipeCD 2. Possible update plugin SDK while develop the SQL plugin 3. Possible update docs how to develop PipeCD plugin 4. Blog about how to develop a PipeCD plugin on https://pipecd.dev/blog/
he wasm-c-api proposal provides the C and C++ API for WASM runtimes. Even though WasmEdge already provided the C API, it's proper to implement the wasm-c-API proposal for the general C/C++ API. In the current status, we've already implemented the non-runtime data structures on the branch. Then, we need to finish the runtime implementation.
KubeEdge has introduced several custom APIs, but currently, there is no corresponding API documentation available. We would like to implement automated generation of API documentation and display it on the website documentation to assist users in quickly understanding the APIs and help developers reduce maintenance costs. Expected Outcome: A tool for automatically generating API documentation.
Help us fight climate change through nature-based solutions! The Full Lands INtegration Tool (FLINT) is a platform for estimating greenhouse gas emissions at local, national and global scales. This project aims to build a cloud deployment framework for rapid deployment of FLINT implementations. This framework will be used in a continuous deployment pipeline (CD) for integration testing and the delivery of FLINT as a service (FLINTcloud) for demonstration purposes. We hope to offer an easy entry point for new users to evaluate the FLINT platform and provide a blueprint for new users to roll their own FLINTcloud deployments. This is critical to help drive the adoption of FLINT and help scale up the monitoring, reporting and validation of carbon emissions and sequestration from land use and land use change around the world. This will involve: 1. Publishing a design for the complete FLINTcloud solution, detailing the required components, technologies and endpoints to be exposed. 2. Exposing the core FLINT routines by wrapping the existing command line interface in a REST API. 3. Creating a simple script to install the prerequisite libraries, FLINT and its modules as a standalone microservice. 4. Creating the deployment framework and setting up a CD pipeline on commodity cloud hardware, favouring automation wherever possible (e.g. infrastructure-as-code). 5. Providing new documentation for the cloud deployment procedure.
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.
Learning paths with hands-on labs are a crucial resource for DevOps engineers and cloud-native practitioners. The Meshery Playground provides a live cluster environment, making it an ideal platform for learning every kind of cloud and cloud native technology. Meshery Docs is in need of comprehensive tutorials and scenarios covering common infrastructure management use cases. Mission is to create and publish a series of hands-on tutorials using Meshery Playground. Each tutorial will include step-by-step guides, live demonstrations, and interactive labs using the Playground allowing learners to apply their knowledge directly without the hassle of any configuration.These tutorials will be reviewed by various project maintainers and then published in guides/tutorials. Expected Outcome: - 10+ new solution architectures (designs) published in Meshery Catalog - Each design is ideally adjoined with an interactive tutorial (using Meshery Playground), guiding users through infrastructure. - Tutorials should vary in complexity, catering to beginners and advanced learners.
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