Explore Projects

Create sustainable open source Ansible modules for creating/managing virtual server instances and storage devices connected to IBM Z. The final target state products could be used to communicate to various storage devices connected to mainframe and control HW function to automate storage managements. Intermediate target state would be communicating to IBM DS8K CLIs and/or RestfulAPIs to help initialization of storage device for virtual servers.

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.

One of the most requested features in Knative Eventing over the past few years has been for triggers in different namespaces than brokers, and for subscriptions in different namespaces than channels. More information can be found in the upstream issue. Expected Outcome: Knative Eventing Triggers and Subscriptions can reference Brokers or Channels in a namespace different from their own if the user possesses the necessary

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

Hyperledger AnonCreds v2 takes the privacy-preserving features of AnonCreds v1 Verifiable Credentials to a new level. AnonCreds v2 adds support for newer, mature cryptosuites (including BBS+ Signatures), and for a number of important Zero Knowledge Proofs (ZKP) that enable an even better balance between verifiability and privacy. AnonCreds v2 also adds a crucial new, highly-scaled approach to ZKP-based credential revocation – a crucial element of almost all verifiable credential ecosystems. Called ALLOSAUR, this new scheme allows a single revocation registry to be created by an verifiable credential issuer that scales to support millions of credentials in a fast, low-data manner. Instead of sharing millions of credential revocation statuses (revoked or not), the scheme relies on the transfer of just a handful of integers between participants, enabling secure revocation without a verifiable credential holder from having to share a correlatable identifer for themself to the verifier. ALLOSAUR requires the creation of a new component in the verifiable credential ecosystem, the revocation manager, which is the goal of this Hyperledger Mentorship – to implement a scalable ALLOSAUR revocation manager. The implementation will at least be partially in Rust, with flexibility on the choice of languages/frameworks for the web service.

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.

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

Managing virtualization workloads on Kubernetes.

A DID registry is a type of verifiable data registry that can be simply referred to as a role, a system performs to mediate the functionalities like create, verify, update, and deactivate the decentralized identifiers. The mentee will have an opportunity to learn -- The application and automation of the Decentralized Identity Hyperledger Aries and Ursa code base -- Public key cryptography -- Application of Hyperledger Ursa in enabling Zero-Knowledge proof -- Git, Shell Scripting, RUST -- Open source contribution, documentation, and sense of ownership Expected Outcome -- Command-Line utility to automate the process of creating a DID Registry for the members of organizations utilizing Github/Gitlab as Verifiable Credential Registry, On-boarding organizations, and features for easy management -- Proper test cases and documentations -- Codebase maintained with proper read me document

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

The build infrastructure for istio.io currently carries a complete archived copy of the site for each release of Istio. These archived versions should be separated to their own branch, with only the supported versions published. We should also separate out content which is not version-specific (e.g. the home page, news and blogs) so that only the latest version of this content is visible online. Expected Outcome: Updated publishing infrastructure for istio.io which separates evergreen content (home page, blogs) with versioned content (documentation). Drop-downs per docs page allow switching between the supported versions.

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.

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.

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.

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

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.

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.

In the Thanos Compactor UI there is visibility of the global block list and loaded block list. But it would be useful to also have a list of planned and currently running compaction groups in order to see what exactly is in progress. This way it would be easier to diagnose what the Thanos Compactor is currently working on, and possibly what is delaying the progress of compactions. This is especially useful if you have large TSDB blocks in S3 buckets that take time to get compacted. Expected Outcome: We have an endpoint in Compactor that details compaction plan, and this is also visualized in a Compactor UI page.

The Zowe Virtual Desktop needs to provide a way to easily transfer files and datasets from the mainframe to a user desktop and vice versa, while dealing with encoding and security.

Increasingly, edge locations are becoming Kubernetes (K8s) based as K8s can support multiple deployment types (Virtual Network Functions, Containerized Network Functions, Virtual Machines and containers). ONAP4K8s is the project that enables ONAP to deploy workloads in K8s based sites. ONAP4K8s enables operators to use a K8s based sites to deploy workloads. In ONAP they can use this to deploy workloads on both Openstack based sites as well K8s based. It also enables usage of common compute resources for both network functions and applications, thereby utilizing compute infrastructure efficiently. ONAP4K8s is being extended to support deploying and connecting apps/services that span across multiple clusters. Major work items where intern can help are – 1. API enhancements 2. Improve code coverage 3. Adding support for application upgrades 4. Adding test cases for new use cases 5. Improving monitoring, tracing, logging of microservices

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)