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.
For the past two years, the Hyperledger Umbra lab has been worked on by mentees to develop the capability of running the unmodified Hyperledger Fabric docker images under a simulated network environment for the purposes of doing experiments on running Fabric networks in a controlled way. At the end of last summer, Hyperledger Umbra achieved the initial goal of running Fabric networks under simulation. Hyperledger Umbra is useful for doing network-level security fuzzing as well as network scaling experiments and this mentorship is focused on designing and executing scaling experiments. Hyperledger Fabric networks are designed to scale up fairly easily, however nobody has actually tried scaling Hyperledger Fabric to many hundreds and thousands of nodes and done analysis on how it affects the characteristics of the distributed system such as time to reach consensus, time to run an election for block creation, etc. The mentee chosen for this project will work with their mentor to design a plan for setting up, executing, gathering and analyzing data, and reporting the results of scaling experiments run at different scales.
Develop a Cactus Chia connector plugin + test infrastructure (container images, container manager class, etc.) from scratch. Include end to end test cases powered by Jest and the said testing infrastructure that prove that the connector is working as intended with a locally simulated Chia network. You will be creating a new package in the Cactus monorepo from scratch under the packages/cactus-plugin-ledger-connector-chia/ path. All the information presented here can also be found at the GitHub issue tracker of Hyperledger Cactus, filed under issue #1634 => github.com/hyperledger/cactus/issues/1634
The Hash Time Locked Contract (HTLC) is a well-known pattern for dis-intermediated asset swaps, i.e., as a mechanism to exchange assets between two parties in two different blockchain networks in an atomic manner without a trusted mediator (or trusted third party). HTLC support has been implemented in the Hyperledger Weaver Labs project, with mechanisms to lock, claim, and unlock assets supported in both the contract and higher application layers. At present, the protocol requires several manual steps by the application users carrying out the exchange or agents acting on their behalf. We would like to automate this process as much as possible by augmenting the relay module in Weaver to communicate events and trigger transactions in foreign networks; this requires both research and software development. Further, HTLC is known to have flaws that could violate system integrity properties, because it relies on parties to execute certain actions by a certain timeout or forever lose the opportunity to carry out those actions; this makes the basic protocol intolerant to system crashes. Research is needed to (provably) determine the best way to make the HTLC protocol fault tolerant, using the features of the blockchain networks maintaining the assets and the Weaver relays mediating the exchange. Augmenting the existing HTLC mechanism within Weaver will provide practical validation of this research.
Extend KubeArmor features to non-Kubernetes environments by implementing karmor recommend for host policies and unorchestrated containers, and enabling dynamic configuration for default posture and visibility through kubearmor.yaml, a new gRPC service, and karmor commands. Enhance karmor profile for host logs, support karmor install for VMs, and validate policies for non-Kubernetes setups. Expected Outcome: User friendly KubeArmor functionality including Application Behaviour and Policy Management in non-Kubernetes environments.
Recently, we have updated the directory and structure of the community's official website documentation. We have listed some documentation improvement tasks. In this project, we would like you to have a thorough understanding of KubeEdge and complete these documentation optimization tasks to help users or developers gain a better understanding of and utilize KubeEdge effectively. Expected Outcome: Document optimization of setup, usage guide, and developer guide, adding more FAQs, etc.
Kmesh, as a high-performance service mesh data plane, is now only supported for use in a single cluster. However, now that multi-cluster support for istiod has been realized, we are able to move forward with the multi-cluster adaptation of Kmesh to support the use of Kmesh in multi-cluster environments. Adaptation to the current multi-cluster production environment with LLM and large data. - Expected Outcome: - 1.Code for implementing the Kmesh multi-cluster feature - 1.1. Adapting to the Istio Multi-Cluster Function API - 1.2. Traffic Management in multi-cluster scenarios - 1.3. Use IPsec to ensure the security of node communication. - 2.userguide doc - 2.1. proposal - 2.2. userguide - 3.e2e test - 3.1. Unit Test of Feature Function - 3.2. E2E test code
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.
The Modeling/etsicatalog project provides VNF/PNF/NS package management service by Micro Service. It also includes a TOSCA parser service which provides generic parser service. As the unified run-time catalog, its VNF/PNF/NS package management interfaces align with SOL003/005 specification. Etsicatalog is a standalone web application based on Python3 and DJango framework. Etsicatalog is going to support SDC Subscription/Notification functions in Guilin version. SDC is the most important design-time component of ONAP. The mentee will be required to make the technical research and take part in the development related this function under the guide of our team. Some work on Alignment with SOL specification for API is also required for the mentee. Besides, We will consider the support for CNF which is a stretch goal (need volunteer）alignment with the CNF task force where applicable.
CoreDNS (https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters to make easy infrastructure management. One such case is certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in https://github.com/coredns/coredns/issues/3460.
his project aims to build an E2E Web dashboard that will display the CI/CD pipeline details of [scheduled](https://litmuschaos.github.io/litmus-e2e/generic-pipeline/pipeline-runs/pod-level-run.html) and [manual](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) runs. It should contain all the litmus backend and portal pipelines and can be easily switched or add more pipelines. Currently, [these](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) are the pipeline present in the e2e.
his project aims to develop AI/ML models for NFV-usecases. Any two of the following three problems can be considered. VNF/CNF resource/performance/failure prediction NFV log analysis with NLP Synthetic monitoring and logging data generation using GANs Learning Objectives ML Techniques: Deep_learning. ML model development AI/ML for Telco Usecases. Interested Interns: DO NOT apply through this platform. Due to a bug, please go to https://wiki.lfnetworking.org/x/EasZB. Read the complete description. When you a ready to apply send your application documents to your Mentor(s) and mentorship@lfnetworking.org
<p>Today most Koordinator scheduler plugins (DeviceShare, NodeNUMAResource, Reservation, etc.) keep their own private cache per scheduling framework/profile, so configuring multiple profiles in a single `KubeSchedulerConfiguration` produces duplicated plugin caches even though the upstream `SchedulerCache` and `PodNominator` are singletons per scheduler instance. This duplication wastes memory, desynchronizes state across profiles, and exposes correctness bugs: in `RunFilterPluginsWithNominatedPods`, `AddPod` is invoked for pods that are still in scheduling and are therefore missing from `nodeDeviceCache`'s used map, which causes DeviceShare and NodeNUMAResource to fail to reserve resources for high-priority pods in RDMA / VF / NV-Switch scenarios. This project will introduce a unified plugin-level Cache and Nominator abstraction that is shared across all profiles in the same scheduler instance, correctly integrates with `Reserve` / `UnReserve` lifecycle hooks, and fixes the `AddPod` / `RemovePod` handling for high-priority device and NUMA workloads.</p><p><br></p><p>Expected Outcome:</p><p> - A shared plugin-level `Cache` and `Nominator` framework exposed to Koordinator scheduler plugins, with a lifecycle tied to the scheduler instance rather than individual profiles</p><p> - Migration of DeviceShare, NodeNUMAResource, and Reservation plugin caches to the shared implementation, removing per-profile duplication</p><p> - Correct `AddPod` / `RemovePod` handling via reused `Reserve` logic that records assignment placements in the nominator, cleared symmetrically on `Reserve` / `UnReserve`</p><p> - Regression and stress tests covering multi-profile scheduling, preemption with nominated pods, and high-priority RDMA / VF / NV-Switch device assignment</p><p> - Developer documentation describing the shared Cache / Nominator API and migration guidance for other plugins</p><p><br></p>
Prometheus recently [announced the second version of it's remote-write protocol](https://prometheus.io/docs/specs/remote_write_spec_2_0/), with support for new features on top of performance and cost savings. The work to be done is contribute support for this new protocol in the OpenTelemtry-Collector-Contrib repository, more specifically to the `prometheusremotewriteexporter` component. Expected Outcome: `prometheusremotewriteexporter` component with support for PRW v2.
he wasm-c-api proposal provides the C and C++ API for WASM runtimes. Even though WasmEdge already provided the C API, it's proper to implement the wasm-c-API proposal for the general C/C++ API. In the current status, we've already implemented the non-runtime data structures on the branch. Then, we need to finish the runtime implementation.
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.
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.
<p>Currently, urunc launches sandbox monitors, such as Firecracker and QEMU</p><p>through command-line invocations. This approach offers limited control over the</p><p>sandbox lifecycle once the process is started. On the other hand, most</p><p>monitors expose remote management interfaces, typically through a socket-based</p><p>API.</p><p><br></p><p>These interfaces provide access to the same operations currently performed via</p><p>CLI, but also enable further control over the sandbox lifecycle. In particular,</p><p>they allow more fine-grained lifecycle management of the sandbox, including</p><p>querying and monitoring its state, performing device hotplug and unplug</p><p>operations and interacting with the guest.</p><p><br></p><p>This project aims to extend urunc's sandbox integration layer to support remote</p><p>management interfaces and to explore each monitor's capabilities in order to</p><p>extend the functionalities of urunc sandboxed containers.</p><p><br></p><p>Expected Outcome:</p><p> - A design document describing the updated architecture and workflow for</p><p> spawning and managing sandbox monitors in urunc.</p><p> - Implementation of the necessary changes in urunc to manage sandbox monitors</p><p> through their respective APIs.</p>
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.
Here in we propose to develop a set of Zowe plugins for the IntelliJ family of development environments. This will ensure uniform user experience, while adding the possibility to work in their favorite development environment. The plugins will share a common foundation to interface with the IntelliJ platform SDK and to access the Zowe resources through Zowe API ML.
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