Linux Foundation 2022 Program Timeline
- Full-Time Terms:
- Spring Term: March 1st - May 31st
- mentorships available on LFX Mentorship: Jan 15th, 2022
- applications open: Jan 15th - Feb 12th (4 weeks)
- application review/admission decisions/HR paperwork: Feb 15th - Feb 26th
- Summer Term: June 1st - August 31st
- mentorships available on LFX Mentorship: April 15th, 2022
- applications open: April 15th - May 14th (4 weeks)
- application review/admission decisions/HR paperwork: May 17th - May 31st
- Fall Term: September 1st - Nov 30th
- mentorships available on LFX Mentorship: July 15th, 2022
- applications open: July 15th - August 12th (4 weeks)
- application review/admission decisions/HR paperwork: August 12th - August 31st
2022 Project Details
About Layer5 and its projects
The Layer5 community represents the largest collection of service mesh projects and their maintainers in the world. Our inclusive and diverse community stewards projects to provide learning environments, create and implement cloud native industry standards, deployment and operational best practices, benchmarks and abstractions, and more. Our pay-it-forward mentality with every contributor (mentee or not) is a shared commitment by all maintainers (and MeshMates - contributor onboarding buddies) to the open source spirit that pushes Layer5 projects like Meshery forward. New members are always welcome.
Meshery is the open source, service mesh management plane for enabling the adoption, operation, and management of any service mesh and their workloads. There are many service meshes available. Software-defined networking is difficult to understand. Meshery’s aim is to make the power of the network available to the rest of us.
About our Community
Layer5 is all about its community of contributors. We have designed an onboarding program customized to meet newcomers where they’re at and developed an onboarding buddy program, MeshMates with individuals dedicated to assisting contributors. Layer5 and Meshery have been around for a year and half and have a healthy, growing community of 300+ contributors. The layer5.io website itself is open source and created by 140+ of our contributors.
Technical writers and other contributors are what comprise Layer5 - an open organization, built for the community by the community. Many student contributors have been placed into new jobs with technology companies like Red Hat, Microsoft, and VMware to name a few of the larger organizations. Layer5 expects much from interns and in return, we put them on stage at DockerCon and KubeCon. We promote them and uplift their works. There are many, many examples of this on the layer5.io websites. A number of former interns are now project maintainers.
LFX Mentorship 2022 Project
About the project
Integration of Open Policy Agent (OPA) and Meshery
Description: As a golang library integrate OPA into Meshery Server, enabling users to define policies to dictate the manner in which their cloud native infrastructure is to both run and be configured. Design an extensible policy framework in which rules may be augmented and dynamically supplied at runtime.
Recommended Skills: golang, rego, reactjs
Upstream Issue (URL): https://github.com/meshery/meshery/issues/544
User Interface Overhaul: State Management w/Apollo/GraphQL
Description: Overcome current architectural issues of: 1) No Caching - In Meshery UI, List of adapters is a state that is being used in multiple components i.e Settings , Dashboard , Connection Wizard and Performance. Refetching the data on every mount of each of these components degrades the user experience. The same goes for all the other data that are being used across multiple components. 2) Multiple Sources of Truth - There is no single source of truth in Meshery UI as all react components manage their own state. Since Meshery UI has to deal with data that frequently changes, like Control Plane Data, Meshsync data etc. it will become hard to keep them in sync if they all manage their own copy of them in their local state.
Recommended Skills: reactjs, apollo, graphql, redux
Upstream Issue (URL): https://github.com/meshery/meshery/issues/5094
Service Mesh Performance
Adaptive Load Controller
- Description: The adaptive load controller is to execute optimization routines recursivley to determine the maximum load a system can sustain. The maximum load is usually defined by the maximum requests per second (rps) the system can handle. The metrics (CPU usage, latency etc) collected from the system under test are the constraints we provide to judge whether a system under test (SUT) is sustaining the load.
A use-case that fits very well is be the ability to use it to run performance tests on a schedule and track the maximum load a system can handle over time. This could give insights to performance improvements or degradations.
Recommended Skills: golang, grpc, docker, kubernetes
Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/350
Convergence of Network and Graph topologies
Description: Use Neo4j's ability to create graph projections, which copy a subgraph to RAM so that algorithms can be efficiently run. This opens the door to leveraging algorithms in the areas of Centrality, Community Detection, Pathfinding, Topological Link Prediction, etc. Bringing to bear advances made in Machine Learning / AI / recommendation systems, fraud detection could really help to derive meaning and comprehension for future tools. Another example is how ML + graph approaches are used to find and determine the optimal molecular structure of atoms such that desired physical properties are targeted. This approach could be applied to the problem of workload sizing and estimation for service mesh operators and would-be adopters.
Recommended Skills: cuelang, golang, neo4j
Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/351
CNCF TAG Network and Observability
Kubernetes ontology and subgraph module design
Description: 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):
a Kubernetes ontology using OWL as a popular (and mature) way of doing this.
a cuelang-based component generator
Recommended Skills: cuelang, golang, neo4j
Previous experience with technical writers or documentation
Our mentors have managed teams of technical writers working on documenting enterprise-grade software at large technology companies (Cisco, Seagate, SolarWinds). During the span of time, he has worked with technical writers in DITA and post-DITA environments (from Word to FrameMaker, structured writing, online help, various CMSes, git). Our mentors have worked with technical writers on documentation strategy, creating document sets, covering the full spectrum of reader personas.