Meshery

Mentors: Student: Olaleye oyewunmi

While Meshery's AWS model catalog contains auto-generated connections for individual services, it currently lacks the critical "cross-model" architectural relationships (like linking an EKS Cluster to EC2 Subnets, or an API Gateway to a Lambda Function) that Site Reliability Engineers need to properly visualize and manage real-world, multi-service cloud deployments on Kanvas. Solution: This project systematically defines these missing inter-model dependencies by combining deep AWS architectural expertise with Meshery's v1alpha3 relationship schema. This involves mapping complex multi-hop infrastructures and accurately structuring evaluation queries, metadata, and mutatorRef/mutatedRef patch paths. Deliverables: 1. A comprehensive audit of cross-model gaps in the current AWS catalog. Implementation of high-priority infrastructural relationships (Networking, IAM Permissions, Firewalls). 2. Definition of complex multi-hop chains (e.g., end-to-end Serverless Event Pipelines, EKS Full Stack dependencies). Visual validation of all new relationships within Kanvas and detailed contributor documentation to guide future model integrations. 3. Definition of complex multi-hop chains (e.g., end-to-end Serverless Event Pipelines, EKS Full Stack dependencies). 4. Visual validation of all new relationships within Kanvas and detailed contributor documentation to guide future model integrations.

Mentors: Student: Lenox Wiltshire

The current approach to request data from the Meshery Server about the relationship between Kubernetes Resources doesn’t scale well due to the need to evaluate through all of the resources every time a request is performed. The proposed solution to this, is to implement a Graph database to store the these resources' relationships to provide faster query responses. I'm going to implement the Graph Database by embedding Cayley (embeddable graph database written in go) into Meshery Server to both efficiently store and retrieve the relationships between the nodes (resources) and hub nodes (cluster, label, annotation, namespace) through the usage of edges (owner_reference, has_label, has_annotation, has_namespace, in_cluster).

Mentors: Student: Khusham Bansal

The Meshery ecosystem's web properties need ongoing frontend modernisation and backend reliability work as they scale. I will deliver performance-optimised UI components, mobile-first responsive fixes, new dynamic sections for the extension ecosystem, and systematic infrastructure improvements, all backed by clear documentation. This builds directly on contributions I have been making since December 2025.

Mentors: Student: Yash Vilas Mahakal

Meshery stands as the canonical cloud-native management plane, rigorously managing the lifecycle, performance, and topologies of multicloud infrastructure. Currently, Meshery manages multiple load generators (Nighthawk, Fortio, Wrk2) to execute Service Mesh Performance (SMP) benchmarks. However, the heavyweight C++ Nighthawk binaries are bundled directly inside the meshery/meshery Go backend container. This statically couples the data plane execution to the control plane, bloating the core image size and preventing independent scaling. This project resolves this architectural flaw by cleanly severing Nighthawk from the core server and wrapping it into an autonomous, standalone gRPC adapter (meshery-nighthawk). To achieve this, I will evolve the existing meshkit/meshes/meshops.proto into a generalized adapters.proto capable of routing both traditional service mesh commands and raw load-generation requests. By the end of this project, Meshery Server will dynamically discover and orchestrate Nighthawk as a first-class out-of-tree component, supported by fully overhauled CLI commands (mesheryctl perf), Helm chart deployments, and a dedicated Meshery UI Adapter chip.

Extensible multi-service mesh orchestrator supporting Istio, Linkerd, and Kubernetes infrastructure deployment.