Skip to content

Latest commit

 

History

History
274 lines (203 loc) · 20.2 KB

File metadata and controls

274 lines (203 loc) · 20.2 KB

Q2

Status: Completed

Timeline

Summer Term: June 1st - August 31st

  • mentorships available on LFX Mentorship: May 3rd, 2021
  • applications open: May 3rd - May 17th (3 weeks)
  • application review/admission decisions/HR paperwork: May 17th - May 31st

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

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

Proposed projects

See the project ideas list.

Participating Projects

Buildpacks

  • Description: As a buildpack user using pack, I would like to be able to inspect the final app image and determine where the source of the code is located as well as what version (keeping in consideration SCM systems) was used.
  • Recommended Skills: Golang, Docker (Containers)
  • Mentor(s): Javier Romero (@jromero)
  • Issue: buildpacks/pack#1139

CoreDNS

  • CoreDNS is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters for make easy infrastructure management. One such case is the certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in coredns/coredns#3460.
  • Recommended Skills: Golang, DNS, TLS, Certificate Management
  • Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)
  • Issue: coredns/coredns#3460

Cortex

  • Description: Cortex is a cloud-native Prometheus compatible monitoring system. It is made up of a set of microservices that can be composed into an architecture that fits multiple use cases. However, this level of flexibility can lead to complexity in the configuration file. One way to handle this complexity is first-class validation support for the config. This is where Cue comes in. Cue provides data validation as a language feature and has solid support for Go. We think enabling Cortex to be configured using Cue and creating a Cue specification for the Cortex configuration file and other file types specific to Cortex would be a good step forward in improving the usability of the project.
  • Recommended Skills: Golang
  • Mentor(s): Jacob Lisi (@jtlisi)
  • Issue: cortexproject/cortex#4095

Keptn

  • Description: As a user, I want to be able to call arbitrary URLs via webhooks that are registered on Keptn events to interact with systems outside of Keptn. Therefore, I would like to use a templating mechanism to define payloads to be able to interact with external systems.
  • Recommended Skills: golang
  • Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)
  • Issue: keptn/keptn#3822
  • Description: Currently, Keptn services and integrations can be found on an overview page at https://keptn.sh/docs/integrations/ While this served fine as a central overview of all currently supported integrations, a more sophisticated "integrations hub" is desired. The hub should list all available integrations including their name, status, install numbers/github stars, description, and installation instructions. The project includes a research task of other hubs and how they are built.
  • Recommended Skills: UX/UI, JavaScript, GoLang (a plus but not mandatory)
  • Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)
  • Issue: keptn/keptn#3406

Racklet

  • Description: “The future is already here - it's just not evenly distributed” - William Gibson

    We’d like to introduce an idea for a new open-source project: Racklet. It’s a fully-integrated, Raspberry Pi form-factor server rack and software stack that aims to be a scale model of hyperscaler datacenters. All layers of the stack are 100% OSS/OSH, and will be developed together with the community. It’s reproducible through open PCB designs, 3D printed casing, and commodity, off-the-shelf hardware.

    We want to lower the barrier of entry for becoming cloud native. Racklet aims to inspire users to explore how modern server architectures work, in a tangible and educational way. Emphasis is put on security, knowledge sharing, extensibility, and portability.

    The goal is to conceptually map to real environments and provide an accessible and well-documented path to welcome future talents to the world of cloud native.

  • Recommended Skills: Go, Rust, Kubernetes, Linux, Raspberry Pi, API and library design, Security, Documentation, GitOps, Embedded Systems, Electronics, Continuous Integration, Virtualization

  • Mentor(s): Davanum Srinivas (@dims)

  • Request For Comments (RFC) Description (URL): https://docs.racklet.io/rfcs/0001-high-level-architecture.html

Tremor

  • Description: Currently tremor supports composition through composing pipelines together, through function composition and through allowing references to query operator definitions and constants in externalizable modules that can be loaded via a module path. It would be excellent if the modularity in tremor extended fully to the query language so that distinct subgraphs could be modularized and consumed by multiple queries to optimise for reuse of flow oriented logic in tremor. This would require extending module support in the tremor query language to support sub-graph definitions with parameters that can be declared and used as part of a higher level query. Modules in tremor-query in their current state: https://docs.tremor.rs/tremor-query/modules/ This project idea involves designing the sub-graph module syntax and semantics and implementing changes to the lexer, grammar, optimizers and runtime. It is most suited to candidates who are interested in programming language evolution and design.

  • Recommended Skills: Rust, Parsers, Programming Language Design/Implementation (Interest)

  • Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)

  • Upstream Issue (URL): tremor-rs/tremor-runtime#940

  • Description: As an early stage project we’ve biased in favour of documenting the essentials and getting content in place as fast as possible. This has worked well but a side-effect is 3 or 4 different sources of content ( www, docs, rfcs and courseware ). In concept with CNCF technical writing and learning best practices use your UX/web design and technical writing expertise for tremor where we as a team are unskilled - make our content awesome and the user experience exceptional. These are some improvements we did think of, but these are neither complete nor required, more suggestions are welcome:
  • Unify the different content forms under a single consolidated theme and design
  • Ease of navigation ( breadcrumbs )
  • Preserve markdown for data entry ( we’re programmers ) and keep design separate ( we’re not designers and find this stuff super hard )
  • A clean, easy to navigate theme with a focus on user experience
  • Well integrated with our CI and doc generation tooling ( think gitops for docs and content ) This task would suit a candidate who is interested in full stack engineering and the complete software development lifecycle with a specific focus or interest in engineering documentation, web design and communicating well designed content to others with a good user experience - exploiting principles of good technical writing and web design of content management systems for technical content consumers.
  • Recommended Skills: UX/UI, technical writing, web design, documentation
  • Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)
  • Upstream Issue (URL): tremor-rs/tremor-www-docs#121

Kyverno

  • Description: Kyverno is a Kubernetes native policy manager that also can be used in a CI/CD pipeline. This project will extend the Kyverno command line tool to support mutate and generate rules and add more E2E/Unit Tests and offer test report based on the results.
  • Recommended Skills: Golang, unit and feature testing.
  • Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)
  • Issue: kyverno/kyverno#1821

Kubernetes Policy Working Group (WG)

The Kubernetes policy working group focuses on developing tools and solutions that make Kubernetes secure and easiser to use.

  • Description: This project will develop an adapter to run Falco in any Kubernetes cluster and periodically generate or update a Policy Report custom resource. The candidate will learn about Kubernetes controllers and various security topics.
  • Recommended Skills: Linux, Golang, CLI, Kubernetes
  • Mentor(s): Jim Bugwadia (@JimBugwadia)
  • Upstream Issue (URL): kubernetes-sigs/wg-policy-prototypes#51
  • Description: This project will develop an adapter to run an image scanning tool (like Clair or Trivy) in any Kubernetes cluster and periodically generate or update a Policy Report custom resource. The candidate will learn about Kubernetes controllers, image security and management, and Kubernetes custom resources.
  • Recommended Skills: Linux, Golang, CLI, Kubernetes
  • Mentor(s): Jim Bugwadia (@JimBugwadia)
  • Upstream Issue (URL): kubernetes-sigs/wg-policy-prototypes#54

Vitess

  • Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. To this end, we would like to add a comprehensive test suite to ensure compatibility with Django framework. The mentee would be introduced to the world of distributed databases and how everything comes together without the user realizing the difference. They would learn how to run Vitess and about comprehensive testing techniques.
  • Recommended Skills: python, django, bash
  • Mentor(s): Manan Gupta (@GuptaManan100)
  • Issue: vitessio/vitess#7905

TiKV

  • Description: TiKV is a distributed KV database. It support using clients in Rust, Golang, Java, C++ and Python, and the Node client is the last missing piece. This program is going to implement Node client on top of Rust client just like Python client and C++ client.
  • Recommended Skills: JavaScript, TypeScript, Rust
  • Mentor(s): Liming Deng (@iosmanthus), Andy Lok (@andylokandy)
  • Issue: tikv/tikv#10054

KubeEdge

  • Description: Edgestream is used to handle the request from apiserver, then forward the request to edged through tunnel. We will find a way to pass-through the request, through the hijack stuff, instead of parsing the web path manually.
  • Recommended Skills: Golang, Kubernetes, KubeEdge
  • Mentor(s): Fei Xu (@fisherxu)
  • Issue: kubeedge/kubeedge#2756
  • Description: Improve the design and content of the kubeedge website.
  • Recommended Skills: JavaScript, KubeEdge
  • Mentor(s): Kevin Wang (@kevin-wangzefeng)
  • Issue: kubeedge/website#70

Thanos

  • Description: The Thanos BlockViewer UI has proven to be an essential part of the debuggability story for the Thanos project. It allows administrators to see the exact state of data in Object Storage in a provider-agnostic way. This project is about extending this UI with richer features, context, and actions to improve observability and increase control.
  • Recommended Skills: React, TypeScript, Golang, ObjectStorage
  • Mentor(s): Prem Saraswat (@onprem), Lucas Servén Marín (@squat)
  • Issue: thanos-io/thanos#3112, thanos-io/thanos#3220, thanos-io/thanos#3221, thanos-io/thanos#3308
  • Description: In order to improve Thanos usage for users, we would like to define our APIs, both HTTP and gRPC, in protobuf/OpenAPI and expose the automatically generated documentation in the website. We also want to define the configuration of our components in protobuf. This would allow users to use tools for documentation, validation, type checking and even code generation to use our APIs efficiently. During this project we also expect collaboration with the Prometheus project to implement similar improvements on Prometheus' side. https://github.com/cncf/mentoring/blob/master/summerofcode/2021.md#port-the-prometheus-api-to-openapi. Optionally we would like to work on the index page on every Thanos component server that will expose those resources for easier debug.
  • Recommended Skills: Golang, Protocol Buffers, Yaml (:
  • Mentor(s): Bartlomiej Plotka (@bwplotka), Prem Saraswat (@onprem)
  • Issue: thanos-io/thanos#4102

OpenEBS

  • Description: Kyverno is a Kubernetes native policy manager that can be used in place of PodSecurityPolicies. OpenEBS helm charts currently set up PSPs for many of its Storage engines. This project is to convert PSPs into corresponding Kyverno policies. The OpenEBS storage engines also uses a custom admission webhook validator. The scope of the project can extend to replacing the custom validators with Kyverno policies.
  • Recommended Skills: Golang, unit and feature testing.
  • Mentor(s): Kiran Mova(@kmova), Prateek Pandey (@prateekpandey14)
  • Issue: openebs/openebs#3385
  • Description: OpenEBS Local PV hostpath is the most simple to use Local PV option available for Kubernetes today. Many of the applications use XFS filesystem to create Local PVs. This project is to implement XFS project quota on the OpenEBS Local PV subdirectory to restrict pods from exceeding the Quota assigned to them via the PVC request.
  • Recommended Skills: Golang, XFS, unit and feature testing.
  • Mentor(s): Kiran Mova(@kmova), Harsh Thakur (@realHarshThakur)
  • Issue: openebs/dynamic-localpv-provisioner#13

Meshery

  • Description: Create the world’s service mesh playground. 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 service mesh learning playground (a running instance of Meshery).
  • Recommended Skills: Golang, ReactJS
  • Mentor(s): Lee Calcote (@lcalcote), Utkarsh Srivastava (@utkarshdev23)
  • Issue: meshery/meshery#2931