Like we mentioned in our previous blog post, CNCF is thrilled to participate in the Fall 2020 CommunityBridge Program and have 22 project ideas from 12 Graduated, Incubating and Sandbox available to mentees. Similar to Google Summer of Code and Outreachy, CommunityBridge is a platform that brings an opportunity to offer paid internships and mentorships to developers interested in getting involved in open source projects.

If you are interested in working on one of the below projects (also on GitHub), you can apply directly on the CommunityBridge platform by September 28.    

Feel free to reach out to us directly if you have any questions or in the #mentoring channel on the CNCF Slack. 



Create Application for Elections Authenticated by External Oauth
  • Description: Create a web-based voting application, with voting logic based on CIVS project, that allows use of external Oauth, such as Github, for voter authentication
  • Recommended Skills: Application development, schedule management, programming
  • Mentor(s): Josh Berkus, Marky Jackson, Jaice Singer DuMars
  • Upstream Issue (URL): Kubernetes community 5096
Kubernetes working group for CSI driver
  • Description: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. This project mainly focus on SMB CSI driver and NFS CSI driver: set up solid unit tests, test coverage data, e2e test pipeline first and then implement a few new CSI features, e.g. dynamc provisioning support, inline volume support, etc.
  • Recommended Skills: golang, Kubernetes
  • Mentor(s): Andy Zhang @andyzhangx
  • Upstream Issue (URL):

Chaos Mesh

Create a debug information collector for Chaos Mesh
  • Description: Create a diagnotic info collector for Chaos Mesh to collect debugging info of a specific chaos experiment, covering chaos-daemon log, tc rules, iptables rules, etc.
  • Recommended Skills: Chaos Mesh, Kubernetes, golang
  • Mentor(s): Keao Yang(@YangKeao), Cwen Yin(@cwen0)
  • Issue:
Support chaos-daemon work independently on a non-k8s node.
  • Description: At present, chaos-daemon can only be run as a daemonset service in the Kubernetes environment, but some users want to inject faults into Kubernetes cluster itself, and they cannot use Chaos Mesh to do this. There are also some users who are unable to use Chaos Mesh because their applications are not deployed in the Kubernetes environment. So we need to make the chaos-daemon component run on non-k8s nodes alone, and inject faults directly into this node to solve the problems mentioned above.
  • Recommended Skills: Chaos Mesh, Kubernetes, golang
  • Mentor(s): Keao Yang(@YangKeao), Cwen Yin(@cwen0)
  • Issue:


Support list-watch from edgecore for applications on the edge
  • Description: Some applications running on the edge side need to connect to the k8s master through list-watch interface, but on the edge it cannot directly connect to the k8s master. So we need forward the list-watch requests to the k8s master through the cloud-side channel.
  • Recommended Skills: KubeEdge, Kubernetes, golang
  • Mentor(s): Kevin Wang(@kevin-wangzefeng), Fei Xu(@fisherxu)
  • Issue:
Use device API both on cloud and edge
  • Description: Now we have defined device API in the cloud side, but the edgeside(edgecore and mapper) still don’t use the API, we should refactor edgeside and use same API on cloud and edge to reduce complexity.
  • Recommended Skills: KubeEdge, Kubernetes, golang
  • Mentor(s): Kevin Wang(@kevin-wangzefeng), Fei Xu(@fisherxu)
  • Issue:
Add EdgeGateway as the ingress gateway on Edge


Support ENUM / SET push down for TiKV Coprocessor
  • Description: Coprocessor is a TiKV component to handle predicate push down. This task is to add ENUM and SET data type to it, so that the performance can be improved in scenarios that involve with these two data types.
  • Recommended Skills: Rust, Database
  • Mentor(s): Chi Zhang (@skyzh)
  • Upstream Issue (URL):

Support rbac control for data accessing in TiKV

  • Description: This task is to support the authorization and authentication ability by rbac control in TiKV, so that the security of the data accessing in TiKV will become more complete.
  • Recommended Skills: Rust, Golang
  • Mentors(s): Song Gao (@yisaer), Yutong Liang (@rleungx)
  • Upstream Issue (URL):


Implement hierarchy queue to better support fair-share
Customize scheduling algorithms per queue
Implement specific job types to improve usability


Keptn CLI to support multiple contexts like KUBECONFIG
Visualize remediation actions as counteractions for alerts


ETW exporter
  • Description: Add exporter for ETW (Event Tracing for Windows) as one of the optional recommended exporters that languages may decide to implement as part of SDK. Initial set of languages to support: C++ and/or C#.
  • Recommended Skills: some C++ or C# coding experience. Windows development environment is needed
  • Mentor(s): @maxgolov
  • Upstream Issue (URL):
OpenTelemetry to FluentBit exporter
  • Description: Define a data format and create an exporter from OpenTelemetry to FluentBit. This will allow customers to use existing log delivery pipeline to upload telemetry collected by the rich set of various OpenTelemetry SDKs.
  • Recommended Skills: one of the languages suported by OpenTelemetry. Ideally C# or Go
  • Mentor(s): @SergeyKanzhelev
  • Upstream Issue (URL):
PHP Exporter Development


Receive: Hashring Update Improvements
  • Description: Currently, any change to the hashring configuration file will trigger all Thanos Receive nodes to flush their multi-TSDBs, causing them to enter an unready state until the flush is complete. This unavailability during a flush allows for a clear state transition, however it can result in downtimes on the order of five minutes for every configuration change. We propose modifying how the Thanos Receive component re-configures itself after the hashring configuration file has changed so that the system experiences no downtime.
  • Recommended Skills: Thanos, Timeseries database, Golang
  • Mentor(s): Lucas Servén Marín(@squat), Frederic Branczyk(@brancz)
  • Upstream Issue (URL):
UI Enhancements
  • Description: The Thanos project has recently migrated its UI to one built on re-usable and shareable components written in React, with the goal of fostering collaboration with the broader Prometheus community. As part of this proposal, we would like to further collaborate with the Prometheus community to continue building a shared UI component library and to contribute upstream to Prometheus so that it can leverage these components in its UI.
  • Recommended Skills: React, JavaScript, Golang
  • Mentor(s): Kemal Akkoyun(@kakkoyun), Bartek Plotka(@bwplotka)
  • Upstream Issue (URL):

Open Service Mesh, Kuma and Service Mesh Interface

Standards validation for OSM and Kuma
  • Description: As two of the service meshes in the CNCF, both Kuma and Open Service Mesh need their implementations of standard specifications validated. This is true for Service Mesh Interface (SMI) and Service Mesh Performance (SMP) specifications. Both API specifications spanning many service meshes. Each service mesh implementing the SMI and SMP specifciation need their conformance validated.
  • Recommended Skills: golang
  • Mentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)
  • Upstream Issue (URL):

Open Service Mesh

Support for WebAssembly filters
  • Description: Bring OSM on par with other service meshes that support WASM filters in their data plane. OSM’s Envoy proxies can be extended at runtime with filters that are running in a WebAssembly sandbox ( Provide ability to dynamically load and unload Envoy WASM filters.
  • Recommended Skills: golang, rust
  • Mentor(s): Lee Calcote (@leecalcote), Dev Kalra (@kalradev)
  • Upstream Issue (URL):


Add various post processing steps in query API after PromQL execution
  • Description: The results from the query/query_range are often unordered w.r.t. the label values and sample value. Also, there is no limit on how many series the endpoint can return. In this project, we want to extend those query APIs to include options for post processing the output to do the following:
  • Support nested sorting (ascending/descending) of time series based on (1) Label values (2) Sample values for /query endpoint.
  • Support limiting the number of time series returned by query/query_range endpoint.
  • If time permits, expore how we can do nested sorting of time series for query_range API.