Explore Projects

Kruise Rollout (https://github.com/openkruise/rollouts) provide plugin-n-play progressive delivery for cloud native apps. The goal of this project is to develop a kubectl plugin so as to visualize rollout progress, e.g. the rollout steps, traffic status and involved pods. The kubectl plugin can leverage the existing kruise kubectl plugin project (https://github.com/openkruise/kruise-tools), and can use the Argo kubectl plugin (https://argo-rollouts.readthedocs.io/en/stable/features/kubectl-plugin/#visualizing-rollouts-and-experiments) as a reference. Expected Outcome: * kruise-tools enhancement for kruise rollout visualization * Well-documented with clear usage instructions and examples

The Zowe Virtual Desktop needs to provide a way to easily transfer files and datasets from the mainframe to a user desktop and vice versa, while dealing with encoding and security.

SidecarSet is an advance workload for sidecar container injection and upgrade. Currently the sidecar container resource must be set explicitely in the sidecar template, however in the cases of traffic proxy, log collection and device emulation etc, it is desirable to to set the resources according to resource of app container. The goal is to support the adaptively setting for sidecar resources and provide best practice for typical use cases. Expected Outcome: 1. Implementation for adaptively resources setting for sidecar in SidecarSet workload 2. Unit and integration tests 3. Documentation for the function usage and typical use cases in the OpenKruise website

The objective of this project is to improve the interoperability of different blockchain networks by developing smart contract gateways that can interact with multiple networks. These gateways will automate, trace, and secure the process of submitting transactions to other blockchain networks. To achieve this goal, the project will involve creating smart contract gateways for various blockchain networks, including those using the same platform, as well as gateways to submit transactions to heterogeneous networks. The initial focus will be on developing gateway smart contracts for connecting multiple separate Hyperledger Fabric networks, and the next step will be to create gateways to connect Hyperledger Fabric to other heterogeneous networks, such as Hyperledger Indy and Besu. The project's primary objective is to evaluate system-level and large-scale integrations, which will be accomplished by setting up an extensive network of blockchains using Hyperledger Fabric as the source blockchain and other networks as destination networks. Overall, the project aims to enhance the efficiency, security, and traceability of cross-blockchain transaction submissions, thereby improving the overall functionality of blockchain technology.

The Kyverno CLI should be flexible enough to perform real variable substitutions when CEL libraries are used in policies, in addition to static substitutions. This enhancement would enable comprehensive policy testing without requiring a real Kubernetes cluster, significantly speeding up development and CI/CD pipelines.

Cloud Native Buildpacks is a specification and set of tools that help you take source code and convert them into OCI images. Sound familiar? Maybe you've heard of Docker, Source-2-Image, Kaniko, etc. Well you are not alone. The goal of this project is to refactor our existing ["features" page](https://buildpacks.io/features/#comparison) to provide an easier to comprehend comparison across other similar solutions. Through this project, you'll research each alternative, learn how they compare and aim to provide that information to the users in an easy to digest format. This will include designing and implementing a better format to compare projects and their features side-by-side.

This project aims to investigate and implement ideas for improving KubeStellar Core Helm chart reliance by contributing improvements to Helm project and reducing its reliance on initContainers for waiting/gathering/processing Kubernetes resources that are used by other containers (for example, KubeFlex Control Planes and their kubeconfigs). 1. Introduce an annotation that would make Helm wait for user- specified resources 2. Introduce priority/coordination of Helm resource creation 3. Introduce an alternative path for dependence chart override values 4. Introduce a mechanism for a chart to require a specified Helm min version or range 5. Introduce an alternative to kubectl initContainers Expected Outcome: 1. A comprehensive investigation of potential alternative methods and approaches 2. Contributions to Helm project to introduce new features that would allow to improve the quality of KubeStellar Core chart 3. A solution implementation that reduces the reliance on kubectl initContainers

PSRAM/HyperRAM is a low pin count DDR-type memory that provides data in sequential address bursts. These memories are fairly large and would be great for applications that require more memory. Block SRAM inside GOWIN's FPGA's are dynamically addressable and are better for use with RISC-V MCUs since they can obtain instructions and data at any address within a clock cycle. However, there is limited amount of BSRAM in most semiconductor devices including FPGAs. A cache between the PSRAM controller bus and the RISC-V processor bus can help fetch instructions/data from PSRAM with sequential addressing and store locally in BSRAM. The processor can then dynamically obtain subsequent instructions and data from the BSRAM within a particular address range. GOWIN already has multiple RISC-V IP cores and PSRAM IP cores in it's IP Core Generator tool. This project would be to develop the cache architecture and RTL that sits in between these two IPs and efficiently trades off the efficiency of using BSRAM for instructions/data versus the storage size/cost benefits of using PSRAM memory.

A proof of concept to add buildkit support to pack in order to build multi-arch images. Pack is the reference implementation of a Cloud Native Buildpacks platform used to build application images from source code. Expected Outcome: Multi-arch support has been one of the most requested features for Cloud Native Buildpacks, and this would allow end-users/developers to build multi-arch images with the pack cli.

Currently, OpenKruise depends solely on the PaaS or CLI to listing OpenKruise workload display and operations. The lack of a general purpose Web-UI greatly hinder the adoption among developer users. This project is about to build a simple Web-UI that can list OpenKruise workload along with the native K8s workload, and support enhanced operation such as container restart or workload rollout. The Web-UI is preferably developed using UI extensions of existing PaaS e.g. Kubesphere and Rancher. Expected Outcome: 1. simple Web-UI 2. integration of the Web-UI with existing PaaS such as KubeSphere (https://dev-guide.kubesphere.io/extension-dev- guide/zh/)

Currently, Kmesh metrics are only reported when a TCP connection is closed. In the case of long connections, it is not possible to know the status before the connection is closed. Therefore, we hope to add the capability to periodically report metrics for long connections. Expected Outcome: 1. proposal 2. code 3. user guide

The Envoy Gateway project provides a simplified way to use Envoy Proxy as an API Gateway, and its documentation is critical to enabling adoption, onboarding new users, and improving developer experience. While the existing documentation covers core concepts and use cases, applying the CNCF Tech Docs Analysis Framework will help assess and systematically enhance its clarity, completeness, and usability. This project aims to evaluate and improve the Envoy Gateway website and documentation (https://gateway.envoyproxy.io/) by leveraging the structured analysis methodology from the CNCF Tech Docs Analysis Framework (https://github.com/cncf/techdocs/blob/main/docs/analysis/howto.md). The outcome will be a comprehensive documentation improvement plan, with targeted updates and best practices implemented. Expected Outcome: 1. Apply the CNCF Tech Docs Analysis Framework to assess Envoy Gateway docs 2. Identify gaps in content, structure, readability, and technical accuracy 3. Improve documentation organization, navigation, and developer onboarding 4. Optimize technical guides, examples, and API references 5. (Stretch Goal) Introduce best practices for continuous documentation improvement

WasmEdge supports PyTorch, TensorFlow Lite, llama.cpp, and more NN backend. Dealing with the text-to-voice is a big thing that we want to achieve. To make it possible, we would like to integrate piper (https://github.com/rhasspy/piper), A fast, local neural text-to-speech system in C++ as a new WASI-NN backend (https://github.com/second-state/wasmedge-wasi-nn). Expected Outcome: 1. A new plugin provides a piper WASI-NN backend 2. A test suite for validating the plugin 3. Documents and examples for explaining how to use the plugin.

<p>We plan to refactor and recode Community AI / ML and HPC (double precision) applications to port them to RISC-V this summer. This is a large, potentially daunting effort but we anticipate building scripts and methods to be able to substantially automate the process. Priority will be given to codes that make the most impact. Here is the initial list of 400 codes we are optimizing and compiling for RISC-V this summer: <a href="https://tinyurl.com/2aau5b9r" rel="noopener noreferrer" target="_blank" style="background-color: rgb(255, 255, 255); color: rgb(17, 85, 204);">https://tinyurl.com/2aau5b9r</a><span style="color: rgb(34, 34, 34);">&nbsp;</span></p><p><br></p>

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.

In the past few quarters, a lot of work has gone into the new Remote Write 2.0 (PROM-35) proposal, and a new spec has been successfully established https://prometheus.io/docs/specs/prw/remote_write_spec_2_0/. But there is still a lot of work that needs to be done to declare it stable, in terms of stability and performance in Prometheus, and general adoption from the wider Prometheus ecosystem. Expected Outcome: Since this is a large initiative, for this round of mentorship, we want to focus on the following tasks, 1. Add 2.0 support to compliance test; make it easy to test write and receive implementations. 2. Ensure RW new features works on agent mode (test for agent mode with metadata-wal-records and type-and-unit features). 3. Ensure Prometheus uses the official RW client

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