Skip to content

Latest commit

 

History

History
375 lines (287 loc) · 32.4 KB

README.md

File metadata and controls

375 lines (287 loc) · 32.4 KB
Raw

Status: Completed

Table of contents

Q2

Status: Accepting applications

Timeline

Note, this has been updated

Summer Term: June 6th - August 31st

  • mentorships available on LFX Mentorship: May 8th, 2021 (no change, existing proposals still available for application)
  • proposals cutoff May 24th
  • applications open: May 9th - May 29th
  • application review/admission decisions/HR paperwork: May 31st - June 3rd

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

  • June 6 (Week 1): Mentorship program begins with the initial work assignments
  • July 15 (End of Week 5): Midterm mentee evaluations and first stipend payments
  • August 31 (End of Week 11): Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals

Accepted Projects

Crossplane

Report breaking changes in CustomResourceDefinition schemas for Pull Requests

  • Description: As Crossplane ecosystem expands, it's not unusual anymore to have 100s of CustomResourceDefinitions in a provider. A big part of this is thanks to code generation tooling we've been building. However, the changes we make with those tools may result in thousands of lines of changes and it's hard to tell whether there is a breaking change in given CustomResourceDefinition in those PRs. Today, we're checking manually to see if there is a breaking change and mark the PR as such so that the notice ends up in the release notes. We can have a GH Action that processes diff in package/crds folder and report breaking changes in the OpenAPI v3 Schemas of CRDs. It'd comment on the PR and automatically label it with breaking-change. This tool would be useful for the whole Kubernetes community that works to extend Kubernetes with CustomResourceDefinitions. We should document the variety of ways to pull packages from popular private registries, and also have testing in place to ensure we don't break any of the mechanisms from release to release.
  • Recommended Skills: golang
  • Mentor(s): Muvaffak Onus (@muvaf), Jared Watts (@jbw976)
  • Upstream Issue (URL): crossplane/crossplane#2863
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06fe8a5b-c3b9-4d12-975f-19f5ec49d006

Document and add automated testing for pulling packages from private registries

Karmada

Cluster Resource modeling

  • Description: In the scheduling progress, the karmada-scheduler makes decisions as per a bunch of factors, one of the factors is the resource details of the cluster. We don't want to collect and store each node's resources in detail(That's a burden for Karmada to maintain the information), but we want to build a resource model for each cluster.
  • Recommended Skills: golang, k8s, algorithm
  • Mentor(s): Hongcai Ren (@RainbowMango)
  • Upstream Issue (URL): karmada-io/karmada#772
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2b3edea5-1f6a-4f6b-a80a-38f5be4ec339

Develop Override policy, Resource Binding, Work Page

Develop Propagation policy, Settings, About Pages

Design & Develop FederatedResourceQuota, SearchRegistry & MultiClusterIngress page

Tremor

Pluggable logging

  • Description: Tremor is an event processing system that can - among other things - process logs and metrics. Currently, Tremor uses log4rs to handle its own logging. We would like tremor to have a facility to handle its logs through its own pipelines (similar to the pluggable metrics experience). A starting point could be a sink for log4rs, which could then be replaced completely, making log4rs an optional output.
  • Recommended Skills: Rust, Testing
  • Mentor(s): Ramona Łuczkiewicz (@agares), Darach Ennis (@darach)
  • Upstream Issue: tremor-rs/tremor-runtime#1621
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1218d516-45af-46a3-977b-e5a9de818cec

Hygenic error handling and validation for pipelines

  • Description: Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the connect statement and the select statement. Currently, neither select nor connect verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.
  • Recommended Skills: Rust, Programming Language Design
  • Mentor(s): Matthias Wahl (@mfelsche), Heinz N. Gies (@Licenser)
  • Upstream Issue: tremor-rs/tremor-runtime#1358
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b503dac3-3b2f-49c5-be17-1d95404ef0a9

Volcano

Official Website Docs Enhancement

Volcano scalability enhancement

KubeArmor

Supporting KubeArmor on ARM platforms

  • Description: KubeArmor has garnered interests from edge computing platforms (such as LF Edge OpenHorizon) that leverages k8s control plane for workload orchestration. The primary requirement is to support ARM platforms that are prevalent on the edge devices (especially Raspberry PI). KubeArmor leverages eBPF for observability and Linux Security Modules (such as AppArmor) for policy enforcement. One of the challenges is to check if the eBPF primitives such as observing kprobe, kretprobe, tracepoints that are typically available on the x86 platform are also available on the ARM platform and check if the parameter list fulfills the requirement. Post this analysis, the KubeArmor code might have to be changed to accommodate any differences in the eBPF behavior.
  • Recommended Skills: golang, raspberry-pi, ebpf, k8s
  • Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)
  • Upstream Issue (URL): kubearmor/KubeArmor#614
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a91eab39-88b3-4a42-82bf-2bd963772acb

Support for OpenShift

  • Description: KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level. This project aims to support KubeArmor on OpenShift. The work will include compatibility analysis of KubeArmor on OpenShift, finding limitations (if any), and eventually testing it on OpenShift.
  • Recommended Skills: OpenShift, k8s
  • Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)
  • Upstream Issue (URL): kubearmor/KubeArmor/#221
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/af03f76c-6253-4efc-b26b-17c522794813

Extend kArmor to include KubeArmor configuration

  • Description: KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level. kArmor is a KubeArmor CLI tool that connects to the kubearmor-relay service to provide command-line telemetry and observability data. The project aims to extend KubeArmor CLI-tool kArmor to check KubeArmor configurations in the running environment. This feature will provide various information about KubeArmor like the current running mode (audit or enforcement), the enforcer used by KubeArmor (SELinux or AppArmor or BPF-LSM), whether it's running in systemd mode or on k8s, etc.
  • Recommended Skills: go, k8s
  • Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)
  • Upstream Issue (URL): kubearmor/kubearmor-client/#19
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/65cabd48-6a5a-4eb6-9e80-4420c152da6a

Thanos

Implement Unified Endpoint Discovery

Description: Thanos Querier microservice is one of the core component of the Thanos system responsible for asking relevent data stores for metrics, labels, metadata, exemplars, targets, alerts and more and merging their results. One of the key challenges to Querier configuration is telling which endpoints it should talk to and what APIs it should expect. For this we proposed the Unified Endoint Discovery idea, which allows consistency and easy to use configuration across all APIs. This project is meant to continue the implementation of this proposal and make sure it works well for all the edge cases using our e2e testing framework. Recommended Skills: Go, DNS Mentor(s): Bartlomiej Plotka (@bwplotka), Saswata Mukherjee (@saswatamcode) Upstream Issue: thanos-io/thanos#5340

WasmEdge

Create a Tokio-like async runtime in WasmEdge

Provide a wasm-compatible Rust TLS implementation

  • Description: The WasmEdge networking socket API provides support for TCP and HTTP connections. But many web services today require HTTPS connections. That means we need to support TLS in WasmEdge. The Rustls crate is the most popular TLS implementation in Rust. However, Rustls is based on the Ring library, which cannot be compiled into WebAssembly. In WasmEdge, we now support the wasi-crypto spec. That allows us to compile the rust-crypto library into WebAssembly and run on WasmEdge. The goal of this project is to create a Rust TLS implementation based on rust-crypto.
  • Recommended Skills: Rust, wasm, crypto
  • Mentor(s): juntao(@juntao), WenShuo Yang(@sonder-joker)
  • Upstream Issue (URL): WasmEdge/WasmEdge#1430
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fca1338f-5be0-41e6-a499-b44e2e722096

Support Durable Objects (DO) in WasmEdge

  • Description: Durable Objects (DO) are persistent data objects available to applications at runtime. They can be stored in a persistent KV store or a data cache. DOs are important for stateful serverless functions. The Anna KVS project developed by UC Berkeley is an autoscaling KVS ideally suited for edge nodes. It is a good match for WasmEdge to support stateful serverless functions on the edge cloud. The goal of this task is to create Rust and JavaScript clients for Anna KVS using the WasmEdge socket API. It allows Rust-based WasmEdge applications to connect to Anna KVS, and store or retrieve DOs in the KVS. Note: A new Rust-based version of Anna KVS is going to be released soon. We will likely use the new version for this task. The network socket API for accessing the KVS will remain largely unchanged from the old version.
  • Recommended Skills: Anna KVS, Rust, wasm, JavaScript, Database
  • Mentor(s): juntao(@juntao)
  • Upstream Issue (URL): WasmEdge/WasmEdge#1431
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/232a19f2-40de-4dfa-8966-2c1586bc6ecc

Implement component-model proposal in WasmEdge

Kyverno

Integrate Kubernetes Pod Security with Kyverno

Kyverno SLSA 3

CLI test schema and enhancements

OpenFunction

Support and update the Python Functions Framework

OpenELB

Support BGP policy in OpenELB

Provide the OpenELB Web UI for managing EIP and IP pool

Meshery

Cloud Native Playground

  • Description: Hosted at play.meshery.io, build a unique learning environment for learning modern application networking through Meshery's support of every service mesh, orchestration of Kubernetes, and integration with many other CNCF projects. Meshery's genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a cloud native playground (a running instance of Meshery).
  • Recommended Skills: Golang, ReactJS
  • Mentor(s): Lee Calcote (@lcalcote), Aditya Chatterjee
  • Issue: meshery/play#16
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bb6cf95e-bbdc-4b50-8446-45507c9e5a6a

Design Configurator

Service Mesh Performance

Implementation of MeshMark

Devfile

Add Compose file support in the spec API

  • Description: Devfiles are YAML files that define development environment running in the cloud. The main part of a Devfile is the components section and specify the containers required to code, build and test an application. 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 update the API specification to allow referencing a Compose file from a Devfile and to implement the support in the Devfile library.
  • Expected outcome: Create a PR against https://github.com/devfile/api to update the spec with the support for Compose files and a PR against https://github.com/devfile/libary to implement it using (the use of an external library such as kompose is recommended). As a stretch goal, implement Compose file support for the DevWorkspace Kubernetes operator too.
  • Expected size of the project: 350h
  • Difficulty rating: Medium
  • Recommended Skills: Golang, Compose, Kubernetes
  • Mentor(s): Mario Loriedo (@l0rd)
  • Upstream Issue (URL): devfile/api#501
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ef552046-cf54-4fe1-ac31-0a1014210e15

Add some syntax sugar to speficy the components that are deployed at startup and those that are not

  • Description: Devfiles are YAML files that define development environment running in the cloud. The main part of a Devfile is the components section and specify the containers required to code, build and test an application. Some components, such as those to code and build the application, need to be deployed as soon as development environment is provisioned. Others instead are supposed to be started later, usually when a command is triggered by the developer to test the applicaiton she is working on (a database for example). The current definition of the latter type of coponents is complicated and not self explanatory. The goal of this project is to add a new component field to specify if the component should be included at startup or not.
  • Expected outcome: Create a PR against https://github.com/devfile/api to update the component spec and a PR against https://github.com/devfile/library to implement it using. As a stretch goal, implement the support for the new field for the DevWorkspace Kubernetes operator too.
  • Expected size of the project: 350h
  • Difficulty rating: Medium
  • Recommended Skills: Golang, Kubernetes
  • Mentor(s): Mario Loriedo (@l0rd)
  • Upstream Issue (URL): devfile/api#852
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3feec75a-3d80-476a-83ab-89ee90f48aad

Cluster API Provider GCP

Add GPU Support

  • Description: Cluster API Provider GCP (a.k.a. CAPG) enables the creation of Kubernetes clusters in GCP with Cluster API. Currently the clusters it creates do not support running workloads in them that take advantage of GPUs and so this rules out things like highly performant machine learning and computational heavy work workloads. We want to enhance CAPG so that it supports GPUs so that users can run these type of workloads. This will require creating a proposal for the change (i.e. design work) and then implementing the propsal which may include changes to the api/controllers, base images and driver installation.
  • Expected outcome: This work will enable CAPG to support the creation of Kubernetes clusters where workfloads can take advantage of GPUs.
  • Difficulty rating: Medium
  • Recommended Skills: Golang, Kubernetes
  • Mentor(s): Carlos Panato (@cpanato), Davanum Srinivas (@dims), Richard Case (@richardcase)
  • Upstream Issue (URL): kubernetes-sigs/cluster-api-provider-gcp#289
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e799bb33-a695-420b-af32-e596938c6960

Vitess

Add complete parsing support for Spatial MySQL functions