Skip to content

Latest commit

 

History

History
420 lines (278 loc) · 28.8 KB

README.md

File metadata and controls

420 lines (278 loc) · 28.8 KB
Raw

Term 03 - 2022 September - November

Status: Completed

Table of Contents

Timeline

Term 3: September 5th - November 30th

Mentorship duration - three months (12 weeks - full-time schedule)

activity date
project proposals August 1 - August 12, 5:00 PM PDT
mentee applications open August 15 - August 24, 5:00 PM PDT
application review/admission decisions/HR paperwork August 25 - September 1, 5:00 PM PDT
Mentorship program begins with the initial work assignments September 5 (Week 1)
Midterm mentee evaluations and first stipend payments October 6 (End of Week 5)
Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals November 16, 5:00 PM PST (End of Week 11)
Last day of term November 30

Project Instructions

Project proposals open August 1st, 2022.

Once opened, Project maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/lfx-mentorship/2022/03-Sept-Nov/project_ideas.md, by August 12th, 2022.

Application instructions

Mentee application instructions can be found on the Program Guidelines page.

Accepted Projects

Cilium

Improving Security posture of the Cilium/Hubble/Tetragon release process

CNCF TAG Contributor Strategy

Mentoring Workspaces - GITHUBUSER.PROJECT.cncf.io (w/ VSCode)

  • Description: pair.sharing.io is a mentoring / pair environment used by ii.nz that brings up clusters to co-learn and co-author via tmate+emacs and a live cluster with many features useful to cloud native development. However, while many folks find the ideas useful, it would be good to reach a wider audience by bringing up workspaces w/ VSCode as an alternative to emacs. The request is for a PoC deploying coder.com to CNCF Infrastructure (likely Packet) and bringing over some of the methods of collaboration learned by ii on pair to a wider audience. "If you want to go fast, go by yourself. If you want to go far, go together." African Proverb – Martha Goedert

  • Recommended Skills: shell, terminals, VSCode, k8s, System Administration

  • Mentor(s): Hippie Hacker (@hh), Caleb Woodbine (@BobyMCBobs)

  • Issue: https://github.com/sharingio/pair/issues/173

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2f5582f4-6cfa-41af-88d2-2bfdd8768756

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

  • Mentor(s): Lee Calcote, Matt Young

  • Issue: cncf/tag-network#21

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/df449a23-ac20-4ee9-8a2c-e0e5d08ba727

Devfile

Add Compose file support in the spec API II

  • Description: Devfiles are YAML files that define remote development environments. The main part of a Devfile is the components section and that's where the containers required to code, build and test an application are specified. The Devfile can either include those containers defintions or reference external files such as Dockerfiles or Kubernetes manifests. The Compose file is a popular format in open source development projects to define runtime environments for testing the application but those cannot be referenced by a Devfile yet. The goal is to continue the work that has been started a couple of months ago to allow referencing a Compose file from a Devfile. The expected outcome is to create a PoC written in go that parses a Compose file such as this one using kompose (as a library, not as an executable) and that creates the objects corresponding to the Compose file services in a Kubernetes cluster.

  • Recommended Skills: Golang, Compose, Kubernetes

  • Mentor(s): Mario Loriedo (@l0rd)

  • Upstream Issue (URL): devfile/api#501

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8b4aeab0-f891-4a67-a510-61393ca38520

Karmada

Enable configurable resource interpreter

KubeArmor

Add BTF and BPF CO-RE Support to KubeArmor

  • Description: Currently KubeArmor depends on kernel headers to use various kernel structures. This creates difficulty in having portability. Linux Kernel versions with BTF (BPF Type Format) information available allows us to write portable BPF CO-RE (or Compile Once - Run Everywhere) applications that can run on multiple kernel versions and configurations without any modification or runtime compilation on the target machine.
    But there is a restriction that CO-RE requires to have the BTF information of the target kernel, which is provided by the kernel itself when it's compiled with CONFIG_DEBUG_INFO_BTF=y. This option was introduced in Linux 5.2.
    For kernels < 5.2 we can use BTFGen to ship BTF information with KubeArmor code or use pahole to generate BTF information from the vmlinux image (with DWARF information) at runtime.
    The project aims to make KubeArmor truly portable across all kernel versions by reducing host environment dependencies.

  • Recommended Skills: Kernel, go, C

  • Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)

  • Issue: kubearmor/KubeArmor#789

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d61e1b05-2a4f-432d-b715-57c818b3e120

Use non-privileged containers for KubeArmor daemonset

  • Description: KubeArmor currently uses privileged mode for its daemonset containers. But it is not a good practice. Privileged containers are usually frowned upon. In many cases, specific admission controllers are deployed to not allow containers to be installed in privileged mode. It is best to not use privileged mode but to define specific capabilities for KubeArmor.
    The aim of the project is to analyse and reduce the system privileges required by KubeArmor, thereby reducing the potential attack surface.

  • Recommended Skills: go, Kernel, k8s

  • Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)

  • Issue: kubearmor/KubeArmor#781

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3cc962b4-cd8b-46ea-9c77-83304145fd51

Kyverno

Policy Exceptions

Enable resource clean-up

Implement new custom JMESPath filters

Logging in JSON plus other enhancements

More support for subresources

Meshery

Integration of Open Policy Agent (OPA) and Meshery

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.

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.

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

  • Mentor(s): Lee Calcote, Nic Jackson

  • Upstream Issue (URL): service-mesh-performance/service-mesh-performance#351

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2c4510d6-7b73-4082-a3f4-209f61767263

Thanos

Receive: Support for tenant-specific external labels

Load balancing of API communication in Thanos

  • Description: Thanos uses gRPC for the majority of network communication. It performs fanouts and sharding of different queries to multiple nodes in a distributed system. Unfortunately, due to the nature of the gRPC, a conventional TCP-based load balancer (e.g. K8s Service) is not enough to distribute requests equally to multiple replicas of the same stateless node. As a result, there is a need to figure out the pragmatic way for Thanos users to load balance requests to multiple backends either by gRPC client load balancing or by guides and integration with popular load balancing proxies like nginx, caddy or envoy.

  • Recommended Skills: Golang, HTTP, gRPC

  • Mentor(s): Bartłomiej Plotka, Aditi Ahuja

  • Upstream Issue (URL): thanos-io/thanos#3016 + thanos-io/thanos#1083

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/de2d206e-32cc-45da-bc5a-1fbc7bc1f5c8

Vitess

Add complete parsing support for Spatial MySQL functions II

Improve evaluation engine

  • Description: Improve the compatbility of Vitess' evaluation engine against MySQL by adding support for more built-in SQL functions.

  • Detailed description: The evaluation engine in Vitess is one of the most critical parts of our query serving infrastructure. This engine is capable of evaluating arbitrary SQL expressions directly inside Vitess' process, without reaching out to a live MySQL instance, and this allows us to plan and execute complex user queries (e.g. queries that contain WHERE and similar filter clauses) between Vitess shards much more efficiently. If you're interested in this GSoC project, your task for the summer will involve continuing the work on this evaluation engine by implementing support for as many built-in SQL functions as possible, using the behavior of MySQL as a reference.

  • Expected outcomes: We expect the Evaluation Engine in Vitess to be close to 100% compatible with MySQL after all the leftover SQL built-ins have been implemented.

  • Recommended Skills: Golang, MySQL

  • Mentor(s): Vicent Marti (@vmg)

  • Expected size of the project: 350h

  • Difficulty rating: Medium

  • Upstream Issue (URL): vitessio/vitess#9647

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/29ec853c-3ab9-4457-ac91-d273fa073d49

Volcano

Pick out reasonable victim pods for rescheduling plugin

Implement pod filter chain for rescheduling

Avoid hot node in dynamic scheduling based on real workload

Integrate Volcano with Ray

Support hot update daemon log level

WasmEdge

Support serialize and deserialize in WasmEdge

Porting OpenVINO on multiple platforms for the WASI-NN proposal in WasmEdge

Node API support for WasmEdge QuickJS

OpenCV SDKs for Wasm in WasmEdge

  • Description: WasmEdge is a leading WebAssembly runtime for AI inference. It supports AI frameworks such as Tensorflow, OpenVINO and PyTorch. A compelling use case is computer vision applications on the edge. Computer vision applications need to pre-process images and videos into tensor formats before applying the AI model. They then often need to overlay the tensor results onto the original image. In our existing demos, we use the Rust image crate to process images. However, the crate only has limited features and is inadequate for many computer vision applications. In the Python-based computer vision applications, the image pre-processing is often done with the Python wrapper for OpenCV library. The OpenCV library itself is written in C and can be compiled into WebAssembly. We would like to create an OpenCV SDK that allows WebAssembly applications to call OpenCV functions.

  • Recommended Skills: C++, WebAssembly, Rust

  • Mentor(s): Michael Yuan ([email protected])

  • Issue: WasmEdge/WasmEdge#1747

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/17fc622c-5674-4381-b597-2f49409fda01