Explore Projects

More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run in a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see [Microshift](https://github.com/openshift/microshift) used as the base platform. Knative consists of Serving and Eventing modules but focusing on Knative Serving as a first step should be more approachable. The project consists of 2 stages. First one is to run Knative on Microshift with minimal resources. This requires finding out problems here, solving them. A stretch goal is to find out what happens with architectures other than x86_64. - Expected outcome: Having Knative Serving with an ingress layer running on top of Microshift. Having a Hello-World Knative Service running on top. Finding issues blocking the edge setup, and possibly fixing them.

WasmEdge provides several AI frameworks as WASI-NN plugins to enable the power of AI/LLM applications for developers and users. We are always eager to add new backends to improve coverage of all models and hardware. BitNet.cpp, released by Microsoft, offers the ability to run 1-bit LLMs quickly without a GPU. We would like to support this framework so that people with limited resources, such as CPU-only hardware, can enjoy the amazing world brought by LLMs. Expected Outcome: i. A new WASI-NN plugin supports BitNet. ii. Use the pure C++ interface from BitNet without any Python dependencies. iii. The plugin must run the model listed in the BitNet repository, e.g., BitNet b1.58 2B4T - Scaling Native 1-bit LLM. iv. A tutorial and example for demonstration. v. A CI workflow for building, testing, and releasing the built assets.

Zowe is a great systems operations tool. One of the systems programmers or performance analyzer's job is to decode SMF/RMF reports to check system's health. Having a generic parser for SMF datasets and/or RMF(or CMF) reports for Zowe would open various opportunities to create/re-use many open-source monitoring tools out there. *

Tenants in Thanos Receivers currently get one external label which indicates their tenant ID. We would like to implement attaching arbitrary external labels to each Thanos Tenant. This functionality is useful for various different use cases, such as improving performance when querying data for tenants which share the same labels.

OPI project is aiming to expand the OpenShift DPU Operator to support NVIDIA, xSight, and/or Mangoboost hardware. The ideal candidate needs to be comfortable at the intersection of infrastructure software and hardware offloading. The expected skill set is a combination of low-level hardware abstraction skills and high-level Kubernetes operator patterns. Technical skills: Golang expertise Github, CI/CD, Linux Networking expertise (Strong understanding of SR-IOV, OVS-DPDK, and virtual functions (VFs)) Familiarity with the OPI APIs and how DPUs handle networking and storage offloading. Experience with developing Kubernetes Operators. Experience with operator-sdk or controller-runtime. They must understand Custom Resource Definitions (CRDs), Reconcile loops, and watch patterns. Understanding Vendor SDKs (ex: DOCA). Optional - Comprehensive knowledge of the OpenShift ecosystem

LLM is a hot topic, there are more and more frameworks to make the execution of LLM faster. WasmEdge already integrated the llama.cpp (https://github.com/ggerganov/llama.cpp) as one of the backend. And we want to bring more. MLX (https://github.com/ml-explore/mlx) is an array framework on Apple silicon created by Apple machine learning research. With MLX, we believe it can have a huge improvement on macOS. Expected Outcome: A new plugin provides a MLX WASI-NN (https://github.com/second-state/wasmedge-wasi-nn) backend, a test suite for validating the plugin, documents and examples for explaining how to use the plugin.

KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge.

AMD chips, with their powerful x86 architecture, exceptional computing performance, and advanced NPUs, demonstrate significant potential in fields such as industrial automation, in-vehicle systems, and high-performance edge computing. Introducing AMD's robust general-purpose and heterogeneous computing capabilities into the KubeEdge ecosystem is crucial for handling increasingly complex and latency-sensitive edge AI applications.However, the deep integration, performance optimization, and best practices between KubeEdge and AMD's high-performance edge platforms—particularly their built-in NPUs and other hardware acceleration units—still require systematic exploration and validation. This project aims to establish a complete link between KubeEdge and AMD edge nodes, building a comprehensive edge computing solution from hardware deployment to NPU acceleration, thereby greatly enriching KubeEdge's hardware ecosystem. Expected Outcome: 1. Debug and support KubeEdge edge nodes running on AMD chips 2. Successfully deploying and managing edge application Pods on AMD-based edge nodes 3. Scheduling and managing AMD NPU resources through KubeEdge to achieve performance acceleration for edge AI inference applications. 4. Implement monitoring and metric collection for nodes, applications, and NPUs 5. Using KubeEdge to achieve the complete platform setup, configuration, and management from the cloud to AMD edge nodes 6. Complete hardware compatib.....

Jaeger-v1 has its own Kubernetes Operator (https://github.com/jaegertracing/jaeger-operator) which deploys Jaeger components according to the deployment strategy as well as the database or datastore. The goal of this project is to develop a new operator for [Jaeger-v2](https://github.com/jaegertracing/jaeger/issues/4843) that achieves feature parity with the v1 operator while introducing improvements and new capabilities. This new operator will leverage the [OpenTelemetry operator](https://github.com/open-telemetry/opentelemetry-operator) for Jaeger-v2 deployment while maintaining and enhancing the storage management features from the v1 operator. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5766). Expected Outcome: By the end of this project, we aim to achieve full feature parity between the Jaeger v2 operator and the v1 operator, with the added benefits of OpenTelemetry integration. The new operator will provide a seamless experience for users, maintaining the robustness and flexibility of v1 while introducing the advantages of v2 and OpenTelemetry.

While generating Package Repository kctrl to create the tar version of the Package Repository instead of pushing the OCI Image to a registry. - Expected Outcome: - Proposal containing design discussions and options considered.

Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the connect statement and the select statement. Currently, neither select nor connect verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.

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.

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.

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

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 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.

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.

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.

ADE - Add additional log support

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.