Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
Performance evaluation of DLTs is a complex process stemming from the inherent complexity of distributed systems. One way to mitigate such complexity is the separation of concerns: use task-oriented solutions for different aspects of the process: - The System Under Test (SUT) is deployed in a representative operating environment. - A dedicated, purpose-specific load generator tool submits representative requests to the SUT. - The SUT is closely monitored during the load generation process, and the measured data is typically stored for post-mortem analysis. - A detailed analysis is performed on the measured data using dedicated data analysis techniques. A summarizing report is the typical final output of the process, containing insights about the SUT. Hyperledger Caliper provides capabilities to integrate lightweight components that can retrieve aggregated results from external components and incorporate them into the generated report. The goal of the project is to provide a single entry/exit point to the performance analysis (once the SUT and its monitoring are configured) by: Providing an open, well-designed, and thoroughly documented side-car service for the detailed performance analysis of distributed Fabric transaction traces. And integrating it into the Caliper load generation and response measurement process as part of the final report. The project will heavily build on the PSWG's Performance Sandbox, aiming to "standardize" its flow and methodologies independently
The goal of this project is to provide a Model Context Protocol (MCP) server that is suitable for production and exposes expected REST endpoints from the European Nucleotide Archive (ENA) as organised, schema-driven tools for AI systems. Although ENA offers robust REST APIs for biological data access, direct integration with AI agents frequently results in inconsistent queries, low reproducibility, and lack of validation. In order to overcome this, the project implements an MCP-based interface layer that ensures predictable execution, provides a strict input/output schemas, and enables secure, secure communication with ENA services. A dynamic tool registry for flexibility, Pydantic for schema validation, httpx for asynchronous API communication, and a response normalisation layer for consistent outputs are all features of the FastMCP-built system. To ensure scalability and production readiness, it will also include a comprehensive error handling, testing, and containerised deployment using Docker and Kubernetes. A fully functional MCP server with several ENA capabilities (such as study, sample, and run queries), thorough test coverage, developer-friendly documentation, and a deployable system that is simple to interface with AI clients are some of the key deliverables. This project will enable more dependable AI-driven scientific workflows by improving the reproducibility, traceability, and accessibility of biological data.
APPLICATIONS ARE CLOSED. Please apply again in the Fall! We will post more information when it is available. Linux is the most widely used operating system in the world. The core software component of the Linux operating system is the kernel. Some of its roles include managing hardware interactions, virtualizing system resources, and enforcing security constraints. In effect, the Linux kernel powers almost all of the world's top supercomputers, android phones, and an innumerable variety of other computers. This course will introduce students to the Linux kernel development by focusing on device driver development, particularly character devices and the /proc and/sys interfaces. This will give students hands-on experience working with internal Linux kernel APIs for hardware access, memory management, DMA and interrupts, among other, and provide an overview of some of the core features and components of the kernel, such as scheduling, system calls, the boot process, and hardware description trees. Gaining an understand of the inner workings of the operating system and how to make changes to it will give students an invaluable perspective on how computers work behind the scenes, which will reveal a new layer of understanding to apply to any future software engineering practice. This is a new format of the following courses we created: https://www.uml.edu/catalog/courses/COMP/3085 or https://www.uml.edu/catalog/courses/COMP/5170
This project aims to make the Ubuntu Desktop Provision installer fully accessible to visually impaired users by addressing key accessibility issues in its Flutter-based interface. Currently, the installer lacks proper screen reader support, suffers from poor keyboard navigation, and fails to provide audio feedback, making it unusable for blind and low-vision users, especially those relying on Accessible-Coconut, a Ubuntu-based distribution developed by Zendalona. The solution involves fixing both architectural and UI-level problems in how Flutter components interact with Linux accessibility frameworks (AT-SPI). It will include: - Implementing semantic accessibility wrappers - Ensuring proper focus and navigation flow - Enhancing screen reader feedback using Orca - Improving the accessibility of complex UI components, such as partitioning - Conducting extensive user testing and providing detailed documentation Deliverables - A fully accessible Ubuntu installer with complete screen reader compatibility - Keyboard-navigable UI with audio cues and meaningful semantic labels - Documentation and developer guidelines for future accessibility improvements - Tested integration with Accessible-Coconut 24.04 This project will enable independent system installation for visually impaired users and contribute long-term value to Flutter-Linux accessibility efforts and the broader open-source community.
This project addresses the critical challenge of GPU resource management in ML/AI research environments where researchers often face delays due to inefficient resource allocation. I'll develop a comprehensive CPU-based control plane that efficiently orchestrates GPU resources through four key components: an advanced job scheduler with priority management and preemption capabilities, a comprehensive observability platform with real-time dashboards, a streamlined model deployment pipeline with CI/CD integration, and robust infrastructure automation. By implementing technologies like Slurm for scheduling, Prometheus/Grafana for monitoring, Terraform/Ansible for infrastructure automation, and integrating ML-specific tools like MLflow and NVIDIA Triton, the system will deliver significant benefits to researchers: reduced wait times for GPU access, transparent visibility into resource availability, priority access for time-sensitive research, and a seamless deployment pipeline from training to serving. Deliverables include a functioning scheduler with priority queue support, a comprehensive monitoring system with custom dashboards, infrastructure-as-code modules, a model deployment pipeline with CI/CD integration, and an intelligent alerting system. The complete solution will serve as a reference implementation for academic GPU cluster management, providing reusable components and best practices for similar infrastructure requirements in the ML research community.
Bio-Block is an open-source healthcare data marketplace on Ethereum and IPFS that handles the full upload → anonymize → encrypt → sell → download lifecycle. However, the pipeline stops at download — once a buyer purchases and decrypts a dataset, there is no way to analyze it inside Bio-Block. This project adds a data analytics layer by introducing a dedicated FastAPI Analytics API (port 3003), a lightweight AnalyticsRegistry smart contract for on-chain result tracking, and a React dashboard for visualizations. The system supports three levels of analysis: graphical (distribution plots, heatmaps, scatter plots via matplotlib/plotly), descriptive (summary statistics, correlation matrices via pandas), and inferential (t-tests, chi-square, ANOVA via scipy/statsmodels). Results are stored on IPFS and linked to their source datasets on-chain via the AnalyticsRegistry contract, maintaining an unbroken chain of custody from data purchase through analysis. Deliverables include: (1) Analytics API microservice with EIP-712 authentication, (2) AnalyticsRegistry.sol smart contract deployed on Sepolia, (3) IPFS result storage and on-chain attestation pipeline, (4) Interactive React analytics dashboard integrated into the existing frontend, (5) Comprehensive test suite (80%+ coverage) and documentation. An optional differential privacy layer using OpenDP is planned as a stretch goal.
The Internet Yellow Pages is a database containing information about internet resources including domain names, autonomous system numbers (ASNs), and subnets, which it receives from 18 organizations including Cisco, Cloudflare, and Stanford University. The data is stored using Neo4j, a graph database known for its flexibility and scalability. It is important that the Internet Yellow Pages contain accurate data from all these sources and provide users with the data quickly and efficiently. However, IHR currently computes a new database of this form each week, and this deployment is not automated, which increases the time it takes to make the new data publicly available. Thus, the goal of this project is to design and implement an automated pipeline to deploy a new database to a remote server each week and to upload the database dump to a public repository. The solution must be maintainable and rigorously tested, with unit tests for each IYP dataset. This ensures that users receive reliable data with no downtime and that future developers can easily expand upon the pipeline. These goals were accomplished by completing the following four subparts: creating unit tests, creating a pipeline to automatically compute a database dump and push it to IHR’s archive, integrating the tests into this pipeline, and extending the pipeline to also deploy a running instance of the database to a remote server. Caddy is used to hotswap newly computed databases and to provide access to previously generated databases.
This proposal aims to implement HTTP/3 communication for Dubbo Triple in the Go language environment, enhancing the connection management capabilities of the Triple protocol in dubbo-go. The proposal will address the compatibility issues between Triple communication in dubbo-go and dubbo-java by implementing keep-alive functionality at the Triple protocol layer. Additionally, the proposal plans to organize and standardize the error codes of the Triple protocol and output necessary log information. By developing a Triple HTTP/3 server and client, seamless and high-performance communication between Dubbo Java and Dubbo Go over the HTTP/3 protocol will be achieved. We will design a connection pool to effectively manage Triple connections and ensure the validity of connections through a PING-PONG mechanism between the server and client, thus realizing keep-alive functionality. Furthermore, the error codes of the Triple protocol will be standardized according to Dubbo Java's standards to facilitate developers in obtaining detailed log information during the debugging process. The final deliverable of the proposal is to achieve high-performance, barrier-free communication between Dubbo Go and Dubbo Java through the Triple protocol, ensuring perfect compatibility and support for interaction via the HTTP/3 protocol. Users will be able to enjoy flexible keep-alive functionality and improve debugging efficiency through standardized error codes.
Linux Kernel Livepatching is the process of replacing functions in the kernel code affected by CVEs with the patch-applied functions during system runtime. It's basically a method to apply security kernel patches to a running system such as a server without rebooting it. Such a feature is crucial for servers running crucial computational tasks 24/7 which cannot afford a reboot. Livepatch module is already provided by the Linux kernel but it's upto the distributions as to how they will be handled. As of 2026, only a few handful amount of distributions like SUSE, Ubuntu and RedHat offer Linux livepatches, which means no community maintained distribution at the moment offers Linux livepatches. There has been a way to utilise Linux livepatching in Debian in the past using kpatch but after the release of Debian 13 Trixie, the support for the kernel in kpatch has been dropped which halted the progress of supporting livepatching in Debian. klp-build is a promising approach to this problem but it only supports SUSE kernels which are only accessible by internal SUSE employees. Debian also lacks a release plan or mechanism to distribute livepatches for kernels. The goal of this proposal is to introduce Linux livepatching in Debian by studying how livepatches can be integrated into Debian and if existing technologies like clang-extract can be integrated into the workflow, forking klp-build to develop dlp-build which will serve as a tool to create livepatches for Debian kernels, as well as proposing a binary format for livepatches and designing a release cycle for the same.
We would like to develop an LLM-based financial data analytics application using open source LLMs, embedding models, the LlamaEdge application server, vector databases, and data processing tools. It will provide an open source "template" and showcase "best practices" for similar applications in this fast growing application area. Expected Outcome: * Create a data processing pipeline in Python or Rust to automatically * collect public company’s SEC 10-Q quarterly reports and press releases. e.g., [Apple 10-Q](https://www.sec.gov/edgar/browse/?CIK=0000320193) and [Apple press release](https://www.apple.com/newsroom/2024/05/apple-reports-second-quarter-results/) * generate a summary for each SEC 10-Q and press release documents using an LLM service such as [LlamaParse](https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/) or [EYELEVEL xRay](https://dashboard.eyelevel.ai/xray/) * create and continuously update a vector database with the summary and original text. The vector is computed from the summary to improve search efficiency. * Create a server-side RAG app that can chat with the vector knowledge base of financial statements. * Evaluate the answer quality * Explore LLM function calling to incorporate real-time information and actions
The Karmada dashboard has already implemented the management of resources in the control plane. Apart from that, we hope to implement the management of resources in the member cluster: once users add Kubernetes resources and the corresponding policy resources on the control plane, they can switch to the corresponding member cluster seamlessly, check the status of Kubernetes resources in the specific member cluster. Kubernetes dashboard is one of the most popular single-cluster management tools, which uses client-go sdk to communicate with the apiserver to manage resources in the cluster. A great deal of client-go related logic can be extended to muli-cluster easily, due to the karmada-aggregated-apiserver component and the compatibility design between Kubernetes resource and Karmada resoruces. So we hope to combine the Kubernetes dashboard with the karmada-aggregated-apiserver component to implement multi-cluster management in the Karmada dashboard. Expected Outcome: 1. Proposal for multi-cluster management base on karmada-aggregated-apiserver. 2. Tools to lift Kubernetes dashboard with specific version into Karmada dashboard repo, and implement management of resources in member cluster based on karmada-aggregated-apiserver. 3. Typical ui for member-cluster management: a. list/detail/delete/update action for deployment resources. b. log viewer for pod. c. web terminal for pod, which user can attach the running pod, and execute temporary commands.
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. This program pairs one mentee with an experienced mentor to deliver a V8 JavaScript engine port for a 32-bit RISC-V core. The V8 JavaScript engine for RISCV64G has been upstreamed to Chromium recently. As a basic component for the Chromium web browser and node.js, it would enlarge RISCV’s application scenario. Although RV32G V8 port would be quite similar to RV64G V8 port , it is still in the TODO list. Porting and enable the RV32G on V8 will bring the embedded RISCV software ecosystem more applications, make RISC-V embed processors more competitive. Deliverables (bullet list of components and the changes expected): - Turbofan backend implementation - Embedded simulator implementation - Corresponding unit tests implementation - Regression tests pass Acceptance criteria (bullet list with measurable results defined): - RV32G cross-compiled and simulator build on both debug and release configuration should be passed - A helloworld demo should run successfully on both the embedded simulator and a real or emulated hardware (i.e. a real board or QEMU emulation). - 97% of the regression test should pass
<h5>End-to-End Testing Support</h5> <p>Oppia Android's current testing corpus includes unit tests using the Robolectric testing framework & integration tests using the Espresso testing framework (to ensure that the app operates as expected in a real Android environment). The current tests have a few limitations: they do not correctly facilitate cross-activity navigation flows which actual users will be triggering, and they do not verify that the app can interact with Oppia's backend correctly.</p> <p>To prepare for the global launch of the app, we need end-to-end tests that:</p> <ul> <li>Verify that the app works as a user would expect by playing through select critical user journeys</li> <li>Verify that the app operates as expected when interacting with a local developer instance of the Oppia backend server</li> </ul> <p>We expect that the tests will be written using UiAutomator & are set up for interacting with a local development server (see <a href="https://developer.android.com/studio/run/emulator-networking.html" target="_blank">relevant documentation</a>).</p> <p>Note that this project requires running Linux with virtualization support (in order to run an Android emulator). You will need to make sure your computer supports <a href="https://help.ubuntu.com/community/KVM/Installation" target="_blank">KVM</a> and is running Linux.</p>
Seeking an escape from daily life chores, many turn to travel as a means of relaxation, renewal, and exploration. However, planning a trip can be overwhelming especially with the abundance of information available online that involves navigating multiple websites, guidebooks and apps to research. Furthermore, discovering the most touristic places in a foreign city or country, along with the best dining spots, shopping locales, and natural vistas, can be a daunting task. The main purpose of this application is to simplify the travel planning experience and inspire users to embark on memorable journeys and discover the most captivating point of interests (POIs) tailored to their preferences. The POIs would be generated by running GEMMA, one of the latest open-source generative text AI models, locally on the AI server in Lleida Lab utilizing Docker technology. Utilizing the liquid galaxy technology, the user would be able to visualize their entire trip on the LG rig with 3 or more screens where the tours along with their info would be sent through KML (keyhole markup language) that will help build beautiful and unique visualizations on the LG rig. In case of unavailability of an LG rig, the user would still have a captivating experience through the app and the integrated google maps. Deliverables - The model trained on the cloud and ready to be inferred in Lleida Lab AI local server. - The new App published on the Play Store under the Liquid Galaxy LAB account. - Full documentation and code on Liquid galaxy lab GitHub.
The Mission Support System (MSS) client currently lacks the ability to save and restore view configurations, requiring users to manually recreate complex window layouts each time they reopen the application. Additionally, collaborative operations do not support sharing view configurations among participants, hindering real-time coordination. To enhance the user experience and collaboration in the Mission Support System (MSS), this project will introduce two major improvements. First, it will implement a local and server-side view restoration system, allowing users to save and reload their window layouts automatically. This will be achieved through JSON-based storage for local configurations and database integration for server-side persistence. Users will have the option to enable or disable view restoration via a new setting, ensuring flexibility. Second, the project will introduce a collaborative view-sharing feature through a dedicated "Manage View" widget. This will enable participants in an operation to share, browse, and load predefined layouts, ensuring consistency during joint missions. The widget will integrate with MSS’s existing operation system, allowing real-time updates via WebSocket notifications. Backend APIs will handle secure storage and retrieval of shared views, while the frontend will provide an intuitive interface for managing layouts. Together, these enhancements will eliminate the need for manual reconfiguration and streamline teamwork in mission planning and analysis.
This project aims to introduce a scalable and maintainable internationalization (i18n) system for applications built using MIT App Inventor. Currently, App Inventor does not provide a structured approach for handling multi-language support, making it difficult for developers to create globally accessible apps. The proposed solution introduces a key-based translation system that decouples user-visible text from UI components. The system integrates across multiple layers of App Inventor, including the Designer, Blockly, runtime, and build system, enabling automatic translation handling in generated applications. Key features include: - Automatic detection of user-visible text from component properties and Blockly blocks - A centralized translation editor for managing multi-language content - Context-based key generation to ensure stability and avoid ambiguity - Runtime translation using JSON for flexibility during development (Companion) - Build-time generation of native Android/iOS resources for efficient production builds The system is designed to be fully backward compatible and supports progressive adoption, allowing existing projects to continue working while enabling developers to gradually migrate to the new translation model. Deliverables include: - A working runtime translation system for App Inventor apps - Integration with Blockly for key-based text handling - Designer-level synchronization and key management - Build-time resource generation for native localization - End-to-end tested implementation with documentation
<p>Krkn-AI's [discover command](https://krkn-chaos.dev/docs/krkn_ai/discover/) connects to a Kubernetes/OpenShift cluster and generates a static configuration file by enumerating cluster components (namespaces, pods, services, PVCs, nodes). While useful, the generated config still requires significant manual work before it can actually be used. Health check URLs are commented-out placeholders, the fitness function defaults to a single hardcoded PromQL query, and scenario selection is static regardless of what exists in the cluster. This issue proposes enhancing discover to produce a dynamic, cluster-aware configuration that is closer to runnable out-of-the-box. By inspecting routes, ingresses, services, and available Prometheus metrics during discovery, we can auto-populate health check URLs, suggest relevant fitness function queries scoped to discovered namespaces, and intelligently enable only the scenarios that apply to the discovered infrastructure.</p><p><br></p><p>Expected Outcome: </p><p> - Auto-discover OpenShift Routes, Kubernetes Ingresses, and Services to populate health check URLs in the generated configuration.</p><p> - Query Prometheus for available metrics to suggest namespace-scoped fitness function queries instead of hardcoded defaults.</p><p> - Intelligently enable chaos scenarios based on discovered cluster components (e.g., PVC, VMI, network interfaces).</p><p><br></p>
The Programs & Events Dashboard tracks editing activity across thousands of Wikimedia programs, but generating a system-wide picture of that impact remains manual and resource-intensive. WMF staff must stitch together per-campaign exports to answer basic questions like "How many total edits have all programs produced this year?" — there is no single place to see the Dashboard's global impact. This project builds that infrastructure in three layers. First, a SystemStat model and SystemStatUpdateWorker (Sidekiq) that computes and caches daily snapshots of global metrics - total edits, pageviews, articles improved, new and retained editors, and per-wiki breakdowns, so that all aggregations are pre-computed and never run on-demand against the full dataset. Second, an asynchronous system-wide CSV export pipeline that allows admins to request a download of all non-private program data, generated in the background and delivered via notification when ready - handling the full data scale without memory exhaustion. Third, a React-based "System Stats" admin dashboard that visualizes global trends, wiki distributions, and editor retention over time, backed by a JSON API endpoint for direct consumption by the WMF Community Data and Evaluation team. Deliverables: SystemStat model + daily background worker; admin-only async CSV export pipeline; "System Stats" React dashboard with trend charts and retention metrics; public JSON API with date-range filtering; full RSpec/Jest test coverage; and end-user documentation for WMF staff.
Project Deliverables • Admin Section : Implement an admin dashboard to manage users, projects, and datasets. Add moderation tools for handling flagged content and project approvals. Implement role-based access control (RBAC) for better user management. • Forking Datasets/Projects : Enable users to fork existing projects and datasets, creating editable copies. Implement versioning & attribution tracking for forked projects. Ensure that forked projects maintain links to original versions. Provide users with a UI to track changes between original and forked projects. • Following/Joining Projects : Allow users to follow projects for updates and notifications. Implement a Join Project feature requiring owner approval for collaborations. • Project Dashboard Improvements : Improve UI/UX for easier navigation and better data organization. Add interactive components for better visualization of project statistics. Enable filtering and sorting options for users to manage multiple projects efficiently. • Notebook Management Enhancements : Enhance notebook versioning, metadata, and organization. Improve JupyterLite integration for a smoother editing experience. Implement a notebook history tracker, allowing users to revert to previous versions. • Publication List Enhancements : Improve publication listing, filtering, and categorization. Enable direct linking to project-related publications. • Versioning & Querying Enhancements : Implement dataset version control for reproducibility. Improve querying components to facilitate advanced data filtering. Enable users to compare different versions of datasets using a visual diff tool.
RIPE Atlas publishes traceroute measurement results. A measurement result can have a large volume of data. One example of a large volume measurement is as mentioned below: "Given around 12000 probes worldwide and the system collects traceroute data from these probes every 15 mins. The measurement has been running for 2+ years. The maximum hops a probe made in this measurement was 32." RIPE Atlas provides a REST API to fetch the measurement result. However, the measurement result object can be a large json response. It increases the memory usage on the server while creating a huge response. If the server succeeds in creating a huge response, the client device may not afford to render an SVG graph given the large traceroute data. The main goal for this project is to enable the visualizer to handle traceroute measurement results of any volume. This can mainly be achieved by - Narrowing down the search according to the inputs (probe ids to include, time frame) provided by the user - Paginate the measurement result API call by probe ids, start time and stop time Experiment rendering the network graph using more efficient graph libraries and test. If by testing, the results are improved then replace the current implementation of v-network-graph. Also, there is a scope for UI enhancements. The main thought process behind thinking UI enhancement for this project was this: "The data which we can provide should simply be there on the graph when the user needs it. This UI enhancement can be achieved by adding another “Detailed mode” to the network graph." During the GSoC timeline, I will be executing testing strategies, fixing the underlying issues of the traceroute visualizer and documenting my work.
Libraries worldwide face challenges in adopting digital lending due to restrictive licenses and costly, vendor-locked systems that limit independence. Lenny is an open-source, self-hosted lending system inspired by the Internet Archive and Koha. Its mission is to give libraries ownership of their digital collections while offering a flexible and cost-effective alternative to proprietary platforms. At its core, Lenny based on python features a FastAPI backend that handles borrowing, returning, and waitlists, with support for Readable, Borrowable, and Print-Disabled books. Security and compliance are provided through LCP DRM and Geo-IP restrictions, while PostgreSQL triggers automate loan expirations. An OPDS feed enables integration with Open Library, Thorium, and other reading systems. Deployment is simple with Docker (Alpine + Nginx), and a React dashboard allows librarians to set lending rules like loan durations and waitlists. To improve accessibility, the companion Lenny-app (TurboRepo monorepo) includes: 1. A sandbox demo preloaded with 500+ e-books to showcase the system in action powered by Lenny. 2. A documentation site that supports integration, open-source contributions, and extensions. Built with TypeScript, React, Next.js, Node.js, and Express.js, Lenny-app is production-ready yet flexible for experimentation. Together, Lenny + Lenny-app deliver both the backend infrastructure and the user interface needed to power community-driven digital lending. By combining secure architecture, a ready-to-use demo, and developer-focused documentation, Lenny provides libraries with a scalable and future-proof solution to manage digital lending independently and expand access for their patrons.
The torchvision package in the mlverse ecosystem provides essential tools for computer vision workflows in R, including datasets, transformations, and model utilities. While the ecosystem has matured significantly, a key limitation remains in the performance of certain core operations, particularly in detection pipelines. Functions such as Non-Maximum Suppression, bounding box transformations, and proposal filtering are currently implemented at the R level, which introduces inefficiencies when working with larger inputs or real-time use cases. This project aims to address that gap by moving performance-critical components into a native C++ backend using torchvisionlib. The approach will focus on identifying the parts of the pipeline that are actual bottlenecks, implementing them in C++ with careful attention to memory usage and batching, and integrating them back into torchvision without changing the user-facing API. Rather than rewriting everything, the work will prioritise targeted optimisations that have a measurable impact on end-to-end performance. In addition to backend improvements, the project will include the implementation of at least one modern computer vision model family, such as YOLO, using the optimised components. If time permits, support for an additional model (e.g., RT-DETR) will also be explored. These models will be integrated into the existing ecosystem with consistent APIs and working examples. The main deliverables of this project are: a set of optimised C++ implementations for core detection operations, their seamless integration into torchvision, at least one fully functional model pipeline built on top of this backend, and supporting documentation and benchmarks demonstrating performance improvements. The goal is to make torchvision not just feature-complete, but efficient enough for practical, large-scale use.
Dynamic Resource Allocation (DRA) is a new feature introduced in Kubernetes version 1.26 and above, providing an Alpha API that allows users to define Kubernetes objects similar to the Persistent Volumes API for generic resources. With DRA, users can separate the declaration of a resource to be consumed from its actual consumption. This move away from the limited "countable" API provided by device plugins allows for a more flexible control over which resources are consumed and where they are allocated. For handling host devices, KubeVirt relies on the Kubernetes device plugin framework, which is crucial for scheduling, allocating, and attaching desired devices and resources to running pods. One limitation of this framework is the lack of persistence in device allocation when the pod is not running. The proposed solution involves implementing the DRA plugin in KubeVirt for PCI passthrough (with Nvme devices as a Proof of Concept). A DRA driver typically consists of two separate but coordinating components: a centralized controller and a node-local kubelet plugin. The kube-scheduler communicates with the centralized controller, which makes allocation decisions based on the overall cluster state and resource availability. The kubelet-plugins are responsible for discovering and advertising the node's available resources to the kubelet. Additionally, the proposed approach suggests enhancing the VirtualMachineInstance (VMI) resource to include resourceClaims under hostDevices. This way, users can create a VMI resource that references a ResourceClaim (Template) which in turn references a registered ResourceClass. KubeVirt components need to be modified to translate the resource claims in the VMI host devices into the PodSpec of the underlying Pod. Finally, the device driver would be deployed along with virt-handler as part of a DaemonSet. In summary, this approach aims to leverage the DRA capabilities to enhance host devices allocation
Apache Airavata MFT is a distributed high-performance, multi-protocol data transfer engine to orchestrate data movement and operations across most cloud and on-premises storages. Agent is the core of this distributed system which does the heavy lifting of transfer jobs. Right now, agents have to be manually deploy and configure to start the transfer. This is a problem for researchers and people who need to transfer data without having much technical skills or time. Updated Proposal Summary: Updated proposal includes creating a desktop application and cybershuttle server to orchestrate the lifecycle management. This will guide cybershuttle agent and MFT agent from cybershuttle server to perform execution of jobs and data transfer, this would also maintain the lifecycle of cybershuttle agent and mft agents. This would help deploy any software and not limited to MFT agents. The proposed solution is to automate the process of deploying and lifecycle management of the agents when a transfer job is submitted from an edge machine. This will help various researchers and people who needs to transfer data from a source to a destination without having much technical skills or time. The deliverables are a piece of code to deploy the agent on various virtual machines, a piece of code to maintain the agent's lifecycle, an automated process for deployment and management, onboarding users and evaluating edge cases, and automated agent placement. The benefits of the proposed solution are that it will make it easy and on the go solution for people even with less technical ability to use the vast speeds and advantages MFT offers. It will save time and effort for researchers and people who need to transfer data from a source to destination. It will make the MFT more user-friendly and accessible to a wider range of people. It not just stops at MFT, in fact users can deploy any containerizable applications using this solution.