Explore Projects

In order to pass sandbox-specific configuration, such as the guest type, monitor type, rootfs information and others, `urunc` relies on a set of [custom OCI annotations](https://urunc.io/package/#annotations). However, these annotations are missing from the container's configuration in non-Kubernetes-deployments. To work around this issue, a `urunc.json` file containing the same information is currently injected into the container’s root filesystem. This works aims to investigate the OCI image build and runtime flow to understand where and why these custom annotations are dropped or ignored in non-Kubernetes setups. - Expected Outcome: - A clear summary of the investigation, including where and why the custom annotations are lost. - A proposed solution enabling `urunc` to correctly consume its custom OCI annotations. - Alternatively, the design and implementation of a cleaner mechanism than injecting a file into the container’s root filesystem.

Support the mutateExisting rule in Kyverno CLI Expected Outcome: - Allow users to be able to apply mutate existing policies to resources from 1. file systems; 2. clusters.

Meshery integrates with many other CNCF projects and technologies. Sustaining those integrations is only possible through automation. End-to-end testing with Playwright, GitHub Workflows, and self-documenting test reports is the means to the end of maintaining a healthy state of each of these [Meshery integrations](https://meshery.io/integrations). Expected Outcome: - Successful migration of E2E tests from Cypress to the Playwright test library within the Meshery project. - Implementation of robust and reliable test cases using Playwright to cover a wide range of Meshery's E2E scenarios. - Documentation detailing the migration process, and guidelines for future contributions to maintain test quality. - Integration of Playwright test suite into the Meshery CI/CD pipeline to ensure continuous testing and reliability of the platform.

Crossplane is in use at scale in many production environments, but we often get feedback that there are many obstacles to learn Crossplane and get to a successfully built production-ready control plane. A major reason for this learning curve is the lack of supporting tools and experiences on top of core Crossplane that could accelerate the community’s attempts to successfully build their platforms. These higher level experiences have recently become a focus for the project and we want to keep delivering awesome experiences that make Crossplane easier to use. Expected Outcome: We expect the mentee to design and code multiple improvements to the Crossplane tooling from the issue linked below. We will start with smaller scoped issues to ramp up and then focus on a bigger deliverable such as adding validation for Crossplane Functions. By the end of the term, the mentee will have multiple code PRs merged into the Crossplane codebase.

This project utilizes Hyperledger Fabric to develop a federated learning framework with committee consensus. Hyperledger Fabric is used for storing and tracing global model update exchange. A customized committee consensus mechanism is required to reduce a load of consensus computation by selecting a random smaller subset of nodes to participate in consensus each round. In order to protect the identity of local data owners, the proposed framework will be integrated with Indy, Aries, and Ursa stack projects to offer self-sovereign identity. The mentee will work with the project mentors to gather and validate the requirements, and design the appropriate technical solution.

Meshery's UI is powerful and utilizes frameworks like Next.js and Material-UI. However, it relies on outdated technology stacks, resulting in performance inefficiencies and increased maintenance overhead. Expected Outcome: Migrate from MUI v4 to MUI v5 and fully utilize features of Nextjs v13. Migrate all class based components to function based component. Reduced code complexity and improved maintainability for long-term sustainability. Responsive and accessible UI that adapts to diverse devices and user needs.

This project focuses on building a robust end-to-end testing framework for the KubeStellar UI using Playwright. The goal is to ensure seamless user experiences by automating critical workflows, enhancing test coverage, and catching UI issues early across various browsers and environments. This includes setting up Playwright from scratch, writing reusable and scalable test suites using the Page Object Model (POM), and integrating these tests into the CI/CD pipeline. Special focus will be given to WebSocket-based testing, authentication, and resource-heavy scenarios in a multi-cluster Kubernetes context. Expected Outcome: 1. End-to-end testing setup with Playwright integrated into the KubeStellar frontend 2. Comprehensive test suites for login, cluster/resource management, and binding policy workflows 3. Page Object Model-based modular test architecture 4. Mocking framework for WebSocket and REST API-based interactions 5. Visual regression testing integrated into GitHub Actions CI 6. Test coverage for key workflows 7. Cross-browser testing across Chromium, Firefox, Safari, and WebKit 8. Flaky test rate under 5% with parallel test execution and retry strategies 9. Documentation for writing, running, and debugging tests locally and in CI

Background: Current flows from RISC-V Sail specification to downstream implementations have manual steps which are time-consuming and can introduce errors.A lack of familiarity with Sail and OCaml presents a barrier to adoption of Sail as the basis for automated downstream implementations: emulators, simulators, compilers, assemblers, disassemblers, instruction stream tools, documentation, etc. Proposal: - Create an accessible Sail backend. - Extract salient information. - Transform it into an accessible database (JSON). - Survey projects dependent on RISC-V ISA for how that dependency is realized. - Utilize JSON to directly and automatically generate downstream source that is currently generated by hand. - Create a React-based interactive RISC-V ISA reference by directly importing the JSON database. Benefits: The backend can serve as a model for creation of additional Sail backends. The JSON database itself may be sufficient for many downstream uses. Creating downstream source shows feasibility, and a process for a fully-automated downstream flow. Additional collaboration with the effort to transform Sail into documentation is warranted. Much of the effort to transform Sail into JSON is complete, but there is still significant effort ahead: - enhanced parsing - enhancing the RISC-V Sail specification itself with more required content Much of the effort in creating an interactive web site is complete, but there is work to support the incorporation, display, and filtering.

<p>Karmada is a multi-cluster orchestration system, but AI coding agents still lack a Karmada-specific skill set. Without a dedicated skill repository, agents often need to search scattered documentation, infer policy structure from incomplete context, and may produce incorrect `PropagationPolicy`, `OverridePolicy`, or troubleshooting guidance. This project aims to build the Karmada skill set for AI coding agents. The design follows mature multi-skill repository patterns, with a shared knowledge base, focused workflow skills, and deterministic helpers for schema-sensitive tasks.</p><p><br></p><p>Expected Outcome:</p><ul><li>A shared knowledge base for policy APIs, policy patterns, troubleshooting cases, component guides, and reusable examples.</li><li>Initial skills:</li><li class="ql-indent-1">karmada-knowledge</li><li class="ql-indent-1">karmada-create-policy </li><li class="ql-indent-1">karmada-audit-policy</li><li class="ql-indent-1">karmada-explain-placement</li><li class="ql-indent-1">karmada-debug-propagation</li><li class="ql-indent-1">karmada-search</li><li class="ql-indent-1">karmada-controller-manager</li><li>Deterministic helper scripts, fixtures, and example scenarios for policy generation, policy review, placement explanation, propagation debugging, and multi-country cluster management.</li><li>Contributor documentation for adding new skills, examples, and knowledge files under hack/agent-skills/.</li></ul>

With WasmEdge serving as one of Runwasi’s standard runtimes, and as our C++-implemented library continues to evolve, we also need a verification process integrated into Runwasi to streamline and validate the stability of both container and cloud environments. Expected Outcome: 1. A concise GitHub workflow demonstrates Runwasi end-to-end testing on Kubernetes. a. Need to design an interactive application scenario that supports multiple nodes b. Try to incorporate the use of the WasmEdge plugin into this scenario 2. Document

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.

Hyperledger Iroha has Smart Contracts from Hyperledger Burrow. It was done in internship project in 2019, then integrated into main Iroha code in version 1.2. Unfortunately integration does not integrate all Iroha commands and queries (currently only: TansferAsset and GetAccountAssets are integrated). So task is to integrate all commands and queries and also permissions. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and optionally Burrow, 3) work in true spirit of open-source, communicating with both Iroha and optionally Burrow community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5) ollowing rules and standards of open-source projects created by hyperledger, 6) Intern would get experience in virtual machines Expected Outcome Documented integration of all Iroha (version 1.x) commands, queries and permissions with unit tests.

Network topologies and graph databases go hand-in-hand. The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph. Deliverables (among other items): - MeshModel capabilities browser - Import/export of MeshModel models and components as OCI images - augmentation of cuelang-based component generator

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.

This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. - Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically: 1. Builds the required Kubespray OS images used in CI for tested distributions. 2. Pushes these built images to the appropriate registry. 3. Cleans up old or no longer needed images but retains those required for supported release branches.

Vitess is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included. Expected Outcome: The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers. Once a decision is made, the mentee is expected to implement the decisions from the maintainer team. The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post. The mentee is expected to review the Getting Started docs (https://vitess.io/docs/20.0/get-started/) on the Vitess website and enhance them to improve the onboarding experience. The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.

The project aims to integrate Graph for Understanding Artifact Composition (GUAC) with in-toto, a framework safeguarding software supply chain integrity. Graph for Understanding Artifact Composition (GUAC) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them. This project seeks to extend in-toto's capabilities by incorporating GUAC, enabling users to query GUAC with Package URLs (purls) and retrieve pertinent attestations. Expected Outcome: Adds functionality to query GUAC, retrieve and parse relevant attestations for the specified artifact.

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

Hyperledger Cactus is a blockchain decentralised integration tool designed to allow users to securely integrate different blockchains started by companies Fujitsu and Accenture. Cactus has pluggable architecture which makes easy to integrate various blockchain by creating plugin, currently plugins for Fabric, Besu, Quorum are implemented. Cactus allows to transfer not only assets but also data between multiple blockchains. On the other hand Iroha (version 1.x) is great with asset management, and has functionality to store data, which makes those two projects a perfect fit! With this internship we will not only allow the interoperability between different blockchains but also create a system of Iroha networks that will also demonstrate the integration in examples easy to run by everybody. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and Cactus, 3) work in true spirit of open-source, communicating with both Iroha and Cactus community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5)following rules and standards of open-source projects created by hyperledger Expected Outcome 1) Documented, ready-to-use integration of Iroha and Cactus, 2) Documented example of integration between multiple (two and more) iroha's networks with Cactus, 3)Documented example of integration between Fabric and Iroha