Explore Projects

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.

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.

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.

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.

ADE - Add additional log support

SDC is the ONAP visual modeling and design tool. It creates internal metadata that describes assets used by all ONAP components, both at design time and run time. The SDC manages the content of a catalog, and logical assemblies of selected catalog items --as needed-- to completely define how and when VNFs are realized in a target environment. A complete virtual assembly of specific catalog items, together with selected workflows and instance configuration data, completely defines how the deployment, activation, and life-cycle management of VNFs are accomplished. Selected sub-assemblies may also be represented in the catalog and may be combined with other catalog items, including other sub-assemblies. ONAP has adopted the CII (Core Infrastructure Initiative) Badge Program. This project will focus to address the remaining Security requirements defined by the ONAP SECCOM Community based on JIRA Backlog.

This project intends to propose a solution to this real-world problem, and it is research-focused. The goal is to give a strong contribution to the Hyperledger ecosystem in terms of the state of the art in blockchain interoperability. Some questions that this project aims to answer are: How can we interoperate Hyperledger technologies with other blockchains?, How can Hyperledger initiatives position themselves to tackle blockchain interoperability?, What standards we require to define middleware between blockchains? What are the consequences of employing smart contracts with external processes and data (the external part means another connected blockchain)?, The key to the survivability of this technology? In other to try to answer those questions, in this project the mentee(s) will start by studying some of the most prominent blockchain interoperability solutions already available or being proposed, and how they can be used to promote and strengthen Hyperledger technologies. Then, the mentee will design and develop a framework for creating, deploying and maintaining services with several blockchains. The applicability of the solution to be proposed is to be demonstrated through the exploration of a use case, implementing several blockchains (including Hyperledger Fabric) to increase the dependability of blockchain-powered services administrated by several stakeholders, serving as a proof-of-concept.

Distributed transactional key-value database, originally created to complement TiDB.

Harbor is a popular and widely adopted container registry. We have developed an initial CLI (https://github.com/goharbor/harbor-cli) that we would like to extend and implement additional functionality, and common workflows that are currently only present in the Web UI. We are seeking a Golangs experienced manatee who can work on the project independently. - Expected Outcome: Working Golang Harbor CLI which can be used in the CI/CD implementations that compliment the Web UI covering the typical workflows of Harbor administrators and users. Familiarity with Golang library spf13/cobra and REST/Open API. Well-documented CLI that users love to use, and with the corresponding architectural diagrams under the Harbor. Working CI/CD with GitHub actions that create multi architecture binaries and containers.

Cluster API (CAPI) provides declarative APIs and tooling to provision, upgrade, and operate Kubernetes clusters. This project continues an existing Headlamp plugin to deliver first-class UI support for CAPI resources (Clusters, Machines, MachineDeployments, KubeadmControlPlanes). The plugin will let operators discover, inspect, and manage cluster lifecycle objects in Headlamp, visualizing hierarchical relationships and closing gaps in the plugin. Expected Outcome: - Sidebar and Map: List key CAPI CRs in the sidebar and Map view; show Clusters with Machines, MachineSets/Deployments, and control planes. - Resource details: Dedicated pages with CAPI-specific fields (conditions, infra refs, provider info, control plane refs, node pools, cluster membership, provider status). - UI integration: Map visualization, sidebar icons, on-hover "Glance" tooltips. - Robustness and tests: Fix runtime errors, human-friendly fields (e.g., "2d5h"), add automated tests. - Polish and delivery: Refined tables, icons, clickable "Controlled by" links; packaged in Headlamp’s plugin repo with install and developer docs; Kubernetes Blog post showcasing benefits.

kruise-game is being used by many game companies. It is imperative to build the stability of kruise-game components. With the rapid iteration of project functions, the current test coverage has not met expectations, so we need to add more UT and E2E use cases to ensure that there will be no problems with our basic functions. In addition, in a large-scale cluster environment, kruise-game also needs more indicators to reveal the performance of the current controller. Expected Outcome: 1. Expand End-to-End (E2E) Test Coverage 2. Improve Unit Test (UT) Coverage 3. Enhance Observability via Controller Metrics 4. Improve Logging Contextualization

<p>Volcano's scheduler has no presence in the dashboard today. Three critical operator workflows are missing:&nbsp;</p><p><br></p><p>(1) Configuration — the entire scheduling policy (6 actions, 22 plugins, per-plugin toggles and arguments) lives in a raw Kubernetes ConfigMap edited only via `kubectl`, with no validation or UI;&nbsp;</p><p>(2) Observability — Volcano exposes rich Prometheus metrics (scheduling latency, preemption counts, unschedulable job/task counts) that the dashboard never queries, leaving operators dependent on a separate Grafana stack;&nbsp;</p><p>(3) Logs — debugging scheduling issues requires `kubectl logs` against pods in `volcano-system`; the dashboard has no log viewing capability at all. This project adds a `/scheduler` section with three tabs: a Config tab that reads and writes the `volcano-scheduler-configmap` as a structured form, a Metrics tab that proxies and visualizes the scheduler's Prometheus `/metrics` endpoint, and a Logs tab that streams live logs from any Volcano system component (`volcano-scheduler`, `volcano-controller-manager`, `volcano-webhook-manager`, `volcano-agent`) — all backed by new tRPC procedures using the existing `CoreV1Api` client in `packages/trpc/server/utils/k8s.ts`.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Config tab: draggable action pipeline editor, plugin tier editor with per-plugin `enabled` toggles and typed argument fields, live YAML diff preview, and a Save button that patches the ConfigMap via `CoreV1Api.patchNamespacedConfigMap`.</li><li>Metrics tab: stat cards for unschedulable jobs/tasks and total preemptions; line chart for e2e and per-plugin scheduling latency; bar chart for per-action latency — all from a new `getMetrics` tRPC procedure querying the scheduler's `/metrics` endpoint.</li><li>Logs tab: component selector dropdown (`scheduler`, `controller-manager`, `webhook-manager`, `agent`), `tailLines` control, keyword filter/highlight, and real-time log streaming via `CoreV1Api.readNamespacedPodLog` with a Server-Sent Events or polling transport.</li><li>Updated RBAC in `deployment/volcano-dashboard.yaml` for ConfigMap `get`/`update` and Pod logs in `volcano-system`.</li><li>Tests and user-facing documentation.</li></ul>

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.

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.

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.

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

Enhance Meshery's existing orchestration capabilities to include support for kro ResourceGraphDefinitions (RGDs) as first-class Meshery Models. This involves enabling Meshery to manage and orchestrate RGDs, similar to how it handles other Kubernetes resources. The project will also include generating support for ResourceGraphDefinition in Meshery's Model generator. Expected Outcome: - Meshery will be able to orchestrate and manage kro RGDs. This includes the ability to deploy, configure, and manage the lifecycle of RGDs through Meshery. The Meshery Model generator will be updated to automatically generate models for kro RGDs, simplifying their integration and management within Meshery. This will be an officially supported feature of Meshery.

In the Thanos Compactor UI there is visibility of the global block list and loaded block list. But it would be useful to also have a list of planned and currently running compaction groups in order to see what exactly is in progress. This way it would be easier to diagnose what the Thanos Compactor is currently working on, and possibly what is delaying the progress of compactions. This is especially useful if you have large TSDB blocks in S3 buckets that take time to get compacted. Expected Outcome: We have an endpoint in Compactor that details compaction plan, and this is also visualized in a Compactor UI page.

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.

Integrated Cloud Native (ICN) Blueprint (BP) family intends to address deployment of workloads at large number of edges and public clouds using Kubernetes (K8s) as resource orchestrator at each site and ONAP4K8s as service level orchestrator across sites. ICN BP is an end2end solution that provides a software stack integrating multiple layers of software such as Service orchestrator, Resource Orchestrator, Software and hardware accelerator plugins etc. Objective of ICN BP is to have single stack for Enterprise, Telco and IoT use cases. Major work items where the intern can help are – 1. Bug fixes and improving installation scripts 2. KUD integration, tuning, and adding new features 3. Maintaining current CI/CD systems 4. Integrating Cluster API into ICN local controller

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)