Explore Projects

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

TiKV is a distributed KV database. It support using clients in Rust, Golang, Java, C++ and Python, and the Node client is the last missing piece. This program is going to implement Node client on top of Rust client just like Python client and C++ client.

Support specifying the deletion propagation policy in cleanup policies and TTL-based cleanup. Expected Outcome: 1. Support specifying the deletion propagation policy in cleanup policies 2. Support specifying the deletion propagation policy with TTL-based cleanup

Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. To this end, we would like to add a comprehensive test suite to ensure compatibility with [Django](https://www.djangoproject.com/) framework. The mentee would be introduced to the world of distributed databases and how everything comes together without the user realizing the difference. They would learn how to run Vitess and about comprehensive testing techniques.

In KubeVela, we use [CUElang](https://cuelang.org/) to code the X-Definition. We want to support auto generation of multiple languages SDK from CUE, so that users can buidling KubeVela Application in their own language. This helps to adoptors to build platform based on KubeVela. - Expected Outcome: Support auto generation of multiple languages SDK from CUE, including Java, Typescript ,Python. This capability should be part of vela CLI command.

MLModelScope (https://mlmodelscope.org/) is a playground that allows people to try ML tasks with various model types, frameworks and hardware backends. It is jointly developed by IBM and University of Illinois. It is currently one of the platforms that collaborate with MLPerf for ML benchmark workload validation. (IBM participates in MLPerf as a founding members, including contribution from z). MLModelScope enables multiple backends for model training, execution and performance study. Currently IBM Z is enabled.

- Description: KubeVela currently have a variety of addons , including experimental options, that address scenarios such as Continual Delivery and observability. To further enhance the out-of-box functionality for users of KubeVela, we can offer additional useful addons. - Expected Outcome: 10+ eperimetal addons, clear documentation should be provided for enabling and using these addons, including examples of useful use-cases.

The Carbon Accounting and Certification Working Group is developing an Operating System for Climate Action, where there is a Hyperledger Fabric Utility Emissions Channel with utility data. Currently, the security certificates for accessing Fabric are held server side. A client application authenticates the user through standard username/password authentication and then access the Fabric chain code on behalf of the user. We would like to explore a client driven authentication for the Fabric application, similar to how Metamask is used with Ethereum dApps such as the Emissions Tokens Network. In such a use case, the user would sign into a web portal, enter and upload their information, and then sign the transaction with a local security key or a dApp wallet such as Metamask. As part of this project, you will learn about 1) Hyperledger Fabric chain code development 2) REST APIs 3) dApp security and wallets 4) Open source development and project management Expected Outcome Implementation of an application with client side authentication for Hyperledger Fabric utility emissions data channel. Documentation and tutorials showing how this is done.

KWOK (Kubernetes WithOut Kubelet) is a toolkit that enables setting up a cluster of thousands of Nodes in seconds. On the KWOK homepage (https://kwok.sigs.k8s.io/), we aim to document the technical outcomes of using KWOK. These outcomes represent the aggregation of some of KWOK's features to achieve a high-level technical goal. Currently, we have the following areas of focus: Chaos Testing, Performance, Simulation, and Scalability. Expected Outcome: A section of the KWOK website detailing these technical outcomes.

We propose to recreate the MIT IoTNet solution in silica. It is currently facilitated by mostly ARM processors and external (USB connected) radios. To do this modernization we are going to design a RISC-V solution that incorporates SDR. We are looking at the trade space now since we know there are some vendors that have products that might be ideal for us. However, we are looking specifically at GNU radio. The background for this project is substantially at https://tinyurl.com/mitiotnet In our first attempts we used TI Beagleboards and Pandaboards. For our next version we will use homegrown MIT Beaverboards and BU Terrierboards. We don’t anticipate having a chip design together soon, either through this effort or our ongoing research. But we may participate with a vendor who already has a board in the marketplace. This of course would depend on whether we could either put an (external) radio on a board or find a way to get our firmware onto the board.

We want to expand the scope of the CloudNativePG tests, introducing a full-fledged chaos testing framework that can be used to better validate the resilience, fault tolerance and recovery mechanisms of CloudNativePG. Expected Outcome: 1. Selection of a Kubernetes-native chaos testing framework (e.g., LitmusChaos or Chaos Mesh). 2. Design and automation of an initial set of chaos experiments covering common failure scenarios. 3. Integration of these experiments into CI/CD to ensure reproducible testing. 4. Collection of clear observability metrics (e.g., failover time, data consistency) to assess resilience and recovery. 5. Documentation and guidelines to help contributors create and run new chaos experiments safely.

GitHub Actions provides detailed views of CI workflows at the repository level, but it can be difficult for maintainers to quickly track the overall status of recurring workflows, such as nightly tests, over time. Important information, like historical failures or trends, often requires manual inspection of individual workflow runs. This work aims to improve CI observability for `urunc` by creating a centralized dashboard that presents an aggregated view of its nightly (and other CI) test workflows. The dashboard will provide maintainers with a clear overview of recent runs, success and failure states, and relevant metadata in a single place. In addition to visualization, this work includes the design and implementation of a notification mechanism that alerts maintainers when tests fail. This will help ensure that regressions are noticed quickly and addressed in a timely manner, improving overall project reliability. - Expected Outcome: - Design and implementation of a dashboard summarizing nightly (and CI) test results. - Clear visualization of workflow status and execution history. - Implementation of a notification system for nightly test failures. - Documentation describing the dashboard, notification setup, and maintenance.

This project continues the work initiated in the etcd - technical scope of the assessment (https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69zcP4/edit?pli=1&tab=t.0#heading=h.o524zy9jn6nn). The goal is to dive deep into etcd's architecture in depth by completing and publishing the self-assessment for SIG-Security review. The project has two key components: (1) collaborating with mentors, project maintainers, and Special Interest Groups (SIGs) to investigate etcd and kube-apiserver internals, particularly the lifecycle of requests and consensus mechanisms, and (2) updating and enhancing the etcd.io website (https://etcd.io/) documentation by creating new pages, refining existing content, and publishing blog posts to ensure the documentation reflects current architecture and best practices. Whether you're a new contributor, already active in the community, or simply curious about etcd, we welcome you to join this project! Expected Outcome: 1. Complete the etcd self-assessment draft currently in progress in this document (https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69) and prepare it for review by SIG-Security and etcd maintainers. 2. Publish the finalized self-assessment in the SIG-Security repository (see example format - https://github.com/kubernetes/sig-security/blob/main/sig-security-assessments/cluster-api/self-assessment.md)............

As organizations from different sectors move their computing workloads across multiple environments, from on-premises to public Cloud to Edge, they require greater assurances that their sensitive code and data are protected. Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment (TEE). To learn more about the Confidential Computing Fellowship, please check the guide below: https://enarx.dev/docs/Fellowship/Introduction Also, please join the #mentorship chat channel at: https://chat.enarx.dev/channel/mentorship

OPNFV VSPERF already includes comprehensive Monitoring solution. However, it lacks the Log-Analysis and Alert-Management solution. This project aims to include log and alert management solutions based on opensources - ELK Stack. This will enhance the ability of VSPERF to: 1. Perform post-test correlation/causation analysis. 2. Adapt the Test-Traffic patterns based on the Alerts. The first aim is to create custom kibana dashboard analyzing and synthesizing VSPERF logs/events. For every test-run, VSPERF generates following logs: 1. vsperf-overall 2. vswitchd 3. trafficgen 4. host-cmds 5. guest-cmds These logs have useful information that can help user to understand the test behavior, and analyze the performance results. VSPERF will have Alerting from the Monitoring component, and lacks alerting from the logs. As the next step, this project aims to use the same information - The logs - and create alerts than will be notified to VSPERF.

<p>Currently, urunc launches sandbox monitors, such as Firecracker and QEMU</p><p>through command-line invocations. This approach offers limited control over the</p><p>sandbox lifecycle once the process is started. On the other hand, most</p><p>monitors expose remote management interfaces, typically through a socket-based</p><p>API.</p><p><br></p><p>These interfaces provide access to the same operations currently performed via</p><p>CLI, but also enable further control over the sandbox lifecycle. In particular,</p><p>they allow more fine-grained lifecycle management of the sandbox, including</p><p>querying and monitoring its state, performing device hotplug and unplug</p><p>operations and interacting with the guest.</p><p><br></p><p>This project aims to extend urunc's sandbox integration layer to support remote</p><p>management interfaces and to explore each monitor's capabilities in order to</p><p>extend the functionalities of urunc sandboxed containers.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- A design document describing the updated architecture and workflow for</p><p>&nbsp;&nbsp;spawning and managing sandbox monitors in urunc.</p><p>&nbsp;- Implementation of the necessary changes in urunc to manage sandbox monitors</p><p>&nbsp;&nbsp;through their respective APIs.</p>

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.

conmon-rs is a container monitor written in Rust, used by CRI-O to monitor a container's lifecycle. Part of its responsibilities is log forwarding--taking the output of the container and writing that output to various places. Currently, conmon-rs supports one format: the one required by the Kubernetes CRI. The goal of this proposal is to add new log formats from the list of standardized ones, like JSON, Splunk, Journald. - Expected outcome: A JSON log driver and Journald log driver are added to conmon-rs. A stretch goal of adding a Splunk log driver is also within scope.

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