Explore Projects

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

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

Codeuino is a volunteer-driven, open-source, social networking software development organization that desires the potential to change the way other communities and individuals use and create open-source social-environment tools to better align with end-user expectations, giving prospectus to various other organizations, users and activists to use the social environments built within Codeuino in a custom way. Donut is an open-source, feature-rich, highly flexible and privacy-friendly, social networking platform built for community-oriented collaboration in a customized way. It has been built on the Node.js framework allowing an essential impetus to provide custom and friendly rich widgets and an expansive library of modules to make communication and collaboration easy and successful. With a powerful module system, you can customize this platform by using third party tools, writing your own, or integrating other software.

The VelaUX API server follows the Open API schema. It could auto-generate the swagger configs via CLI. When VelaUX frontend or other projects need to call these API, they must write the model code and request the API code. We can provide SDK for them to start faster. [OpenAPI generator](https://openapi-generator.tech/) could help to generate most codes. But there are still some special cases like: - Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE. - Automatically handles the user authentication process, including automatically refreshing tokens. - The API definition may be incomplete accuracy, we should check it to generate high-quality code. - Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server: - VelaUX APIServer TypeScript SDK - VelaUX APIServer Java SDK

Leading Open Source Container Attached Storage, built using Cloud Native Architecture, simplifies running Stateful Applications on Kubernetes.

The proposed project includes the following key activities: A systematic review of the applicability of fault-tolerant software patterns to Hyperledger Fabric chaincode as the potentially faulty software Creation of programming idioms for applying the applicable patterns to Hyperledger Fabric chaincode Prototyping "fault tolerance gadgets" (libraries) for easy application to chaincode The book "Patterns for Fault Tolerant Software" from R. Hanmer (Wiley, 2013) is a good reference of the patterns that the project will target. This is a research-focused project which is relatively light on programming. At the same time, a rather deep dive into the workings of Hyperledger Fabric is expected.

This internship is about O-RAN-SC code quality improvement and clean-up. The work involves: Tagging consistency - work with LF-RelEng and PTLs Documentation (release notes, broken-links, etc.) Fix Stale dockerfiles - containers to be rebuilt. Artifacts publishing (proper links to containers for every release) User-guide evaluation - ensure the steps are still valid on Kubernetes Cluster. Appropriate (PTL/Project defined) actions around CVEs Evaluate and analyze reports Document the policy. Possibly fix the ‘critical’ ones - based on inputs from PTLs. Document best-practices, new-ptl onboarding, etc.

Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Move2Kube has a very plugin friendly architecture, users can write custom logic in the form of "Transformers" that Move2Kube can integrate seamlessly into its transformation pipeline. So far we have support for both Starlark and container image based transformers. We would like to support writing transformers as WASM modules that Move2Kube can run. WASM provides extensive sandboxing for security, it allows writing transformers in different language stacks like Rust, C/C++, etc. other than Golang, and WASM is just as lightweight and fast as Starlark. - Expected Outcome: - Implement a feature in Move2Kube CLI to allow running WASM modules as custom transformers.

Jenkins is an open source automation server. It provides thousands of plugins to support building, testing, deploying and automating virtually any project at any scale. Your donations help to keep the project going and to accelerate its evolution. More information about how we use donations: https://jenkins.io/donate/

We plan to have students download and modify processor core code bases to include a number of different numerical notation options. We will try a number of variations to get either multiple functions or a single optimized numerical notations.

Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. To improve the usability of OpenEBS, the proposal is to have easy to use OpenEBS CLI (similar to kubectl) to perform operations like: - upgrade => Upgrade OpenEBS pools and volumes - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes. - version => Print the OpenEBS version and associated images - describe => Describe OpenEBS component status like component/control plane, pools and volumes. - create => Create OpenEBS resources - delete => Delete OpenEBS resources

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.

Managing virtualization workloads on Kubernetes.

The Karmada Certificate Lifecycle Management project addresses user challenges in certificate management, focusing on mitigating service disruptions and security risks due to expirations. Key goals include implementing a feature for real-time monitoring of certificates with advance notification for upcoming expirations; creating a comprehensive manual for manual replacement with best practices and visuals; allowing configurable certificate validity during deployment via CLI, Helm charts, and Operator; and designing an automated certificate rotation system to streamline certificate maintenance and ensure continuous security across Karmada environments. Expected Outcome: Certificate Visibility Tool/Feature, Manual Certificate Replacement Guide, Updated Installation Tools with Customizable Certificate Validity, and Automated Certificate Rotation Solution Design or Integration Recommended Skills: Golang, Kubernetes Admin, certificate management, Helm. Upstream Issue: karmada-io/community#69

Hyperledger Umbra is a Hyperledger Lab designed to run unmodified versions of our DLT platforms (e.g. Hyperledger Fabric, Hyperledger Iroha) under a simulated environment with software defined networking for the purposes of running experiments (e.g. scaling experiments, consensus algorithm development, etc) and security audits. Currently Hyperledger Umbra can run unmodified Hyperledger Fabric Docker images and execute a full Fabric network under simulation. Umbra is written in Python and has code for doing virtual network switches and connections. This project is to extend that code to allow for network fuzzing capabilities. The goal is to be able to introduce packet drops, packet delay, packet reordering, as well as unsolicited packets with random/known-bad data. The purpose it be able to test Hyperledger Fabric's resilience to general network "weather" and intentional attacks coming from the network.

Cross-chain bridges are a vital part of the blockchain landscape as they enable data and value to move seamlessly across different blockchains. Security is of utmost importance in this area, as these bridges can be vulnerable to malicious attacks and manipulation. In addition to securing bridges, measuring their performance and scalability is key to understanding if one is meeting the highest standards and is capable of encountering users' needs. This is mandatory to achieve mass adoption of the technology by single users and businesses. There have been some efforts to design and implement interoperability solutions across different blockchains, some of which are within the Hyperledger ecosystem (see links in the next section). Furthermore, preliminary research has been conducted to benchmark interoperability solutions, however, we feel there is currently a lack of studies that thoroughly compare bridges – used both within and between Hyperledger and public blockchains used in the industry. We aim to address this gap and conduct such evaluation studies, mainly through benchmarking. The goal of this project is to benchmark cross-chain solutions, an essential step for measuring the performance of any solution. As the adoption of cross-chain bridges grows it is increasingly important to have benchmarks to measure cross-chain solutions' performance and security.

Help us fight climate change through nature-based solutions! The Full Lands INtegration Tool (FLINT) is a platform for estimating greenhouse gas emissions at local, national and global scales. This project aims to build a cloud deployment framework for rapid deployment of FLINT implementations. This framework will be used in a continuous deployment pipeline (CD) for integration testing and the delivery of FLINT as a service (FLINTcloud) for demonstration purposes. We hope to offer an easy entry point for new users to evaluate the FLINT platform and provide a blueprint for new users to roll their own FLINTcloud deployments. This is critical to help drive the adoption of FLINT and help scale up the monitoring, reporting and validation of carbon emissions and sequestration from land use and land use change around the world. This will involve: 1. Publishing a design for the complete FLINTcloud solution, detailing the required components, technologies and endpoints to be exposed. 2. Exposing the core FLINT routines by wrapping the existing command line interface in a REST API. 3. Creating a simple script to install the prerequisite libraries, FLINT and its modules as a standalone microservice. 4. Creating the deployment framework and setting up a CD pipeline on commodity cloud hardware, favouring automation wherever possible (e.g. infrastructure-as-code). 5. Providing new documentation for the cloud deployment procedure.

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

KubeFlex is a flexible and scalable platform for running lightweight Kubernetes control plane APIs to support specific use-cases in cloud and edge computing environments. It supports various kinds of control planes, such as: vcluster, ocm, host, etc. This project aims to extend KubeFlex to support a new type of control plane that provides the full components of a control plane in a typical Kubernetes cluster (e.g., API Server, Scheduler, Controller-Manager, etc.). This new control plane will be based on K3s and it will allow KubeFlex to support new use-cases such as multi-tenant scenarios. Expected Outcome: A new type of KubeFlex provided control plane based on k3s

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.

The mentee will work on updating the Getting Started chapter with updates from Zowe, add new and updated content to the Advanced chapter, review issues, and work on incorporating those that will add value to the course offering and be part of the release team, releasing the next version of the course

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.