Explore Projects

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.

Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI, so that a powerful, real-time user experience is possible.

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.

<p>Ianvs serves as the KubeEdge SIG AI distributed benchmark toolkit. As more and more contributors running, KubeEdge Ianvs now has up to 30 examples, and the number is still increasing. KubeEdge Ianvs then faces mounting usability issues due to dependency evolution and validation mechanisms. As Python versions, third-party libraries, and Ianvs features advance, partial historical examples fail to execute. This has led to surging user-reported Issues from confused contributors, untested PRs breaking core functionality of legacy features, and severely outdated documentation misaligning with actual capabilities. Without systematic intervention, the example risks becoming obsolete for edge-AI developers and especially newcomers. We then try to resurrect Ianvs’ usability with a comprehensive example restoration.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Diagnose &amp; fix bugs across examples, including dependency manifests, license scan, and runtime configurations.</p><p>&nbsp;- Documentation Modernization, including revamp tutorials with reproducible step-by-step guides, publish developer-focused debugging playbooks for common failures. Write and upload the corresponding blog to the KubeEdge Website.</p><p>&nbsp;- Advanced: Build a CI pipeline testing examples with GitHub Actions against multiple Python versions, critical Ianvs/upstream updates, and block PRs that break validated examples</p><p><br></p>

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

Konveyor provides a [unified experience](https://github.com/konveyor/enhancements/tree/master/enhancements/unified_experience) of tools to help organizations modernize their applications at scale to Kubernetes and cloud-native technologies. We are looking for help on extending a use-case of detecting usage of [deprecated and removed Kubernetes APIs](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) in applications. This work will involve determining what API resources have been deprecated or removed in each version of Kubernetes and then building [Analyzer Rules](https://github.com/konveyor/analyzer-lsp/blob/main/docs/rules.md) to be contributed to our [Rulesets repository](https://github.com/konveyor/rulesets), curation or development of sample applications in Golang, Java, and YAML to aid test scenarios, and documentation to help show a guided walkthrough of this capability. You can see the beginning of this use-case being addressed with a [sample rule](https://github.com/konveyor/analyzer-lsp/blob/main/rule-example.yaml#L42-L45) in this [demo of analyzer-lsp](https://github.com/konveyor/analyzer-lsp/tree/main#quick-demo). The development environment is based on Golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems.

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

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. Currently only memory storage is wired in v2, we need to add Elasticsearch, Opensearch, Cassandra, Badger. Expected Outcome: Build out full support in jaeger-v2 for all storage backends supported by jaeger-v1

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.

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.

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.

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.

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.

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.

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

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.

Cacti provides modules, toolkit, and protocols to enable networks built on distributed ledgers to interoperate and carry out transactions spanning their boundaries, such as asset transfers, asset swapping, and ledger data communication. For ease of building DLT-agnostic protocols in Cacti, we need to build modules corresponding to various DLTs supported by Cacti that implement these core operators and expose them using a standard API. The goals of this project are as follows: 1. Design and build DLT-specific core operator modules for Cacti by leveraging existing Cactus or Weaver packages. This involves identifying building blocks of unique features in either, and integrating legacy Cactus and Weaver packages wherever they offer a common feature. 2. Design and implement a common DLT-agnostic API, following the OpenAPI standard, using which any DLT-specific core operator module can be invoked by application-specific business logic on-demand. 3. Add suitable API support within the common Cacti client API for ease of application development 4. Do a research survey of existing blockchain/DLT literature to identify a potentially exhaustive set of core operators any DLT network must possess (or harness) to interoperate with other networks.

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.