Skip to content

Latest commit

 

History

History
620 lines (505 loc) · 49.1 KB

README.md

File metadata and controls

620 lines (505 loc) · 49.1 KB

Term 02 - 2023 June - August

Status: Complete

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

Timeline

activity date
project proposals due Tue, May 9, 5:00 PM PDT
mentee applications open Wed May 10 - Tue May 23, 5:00 PM PDT
application review/admission decisions Wed May 24 - Mon May 29, 5:00 PM PDT
Mentorship program begins with the initial work assignments Thur June 1 (Week 1)
Midterm mentee evaluations and first stipend payments Wed July 12 (Week 6)
Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals Wed Aug 23, 5:00 PM PST (Week 12)
Last day of term Thur Aug 31

Project Instructions

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/programs/lfx-mentorship/2023/02-Jun-Aug/project_ideas.md, by Tuesday, May 9, 2023.

Application instructions

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

Table of Contents

Accepted projects

Armada

Build interfaces around Postgres for Armada

Cilium/Tetragon

Implement a Kubernetes operator to maintain pod IP to pod metadata mapping

  • Description:

    Tetragon currently depends on Cilium to look up pod information by their IP addresses. The goal of this project is to remove this Cilium dependency by implementing a Kubernetes operator that provides this information. The idea is for this operator to maintain a new custom resource that provide a mapping from IPs to the small subset of pod information that Tetragon needs.

  • Expected Outcome:

    • A Kubernetes operator that maintains IP to pod info mapping used by Tetragon.
    • The operator should be installable via Helm as a Kubernetes deployment.
    • Replace Cilium dependency in the code base with this new custom resource.
    • Some performance benchmarks in a high pod churn environment.

  • Recommended Skills:

    • Goassign
    • Kubernetes

  • Mentor(s):

  • Upstream Issue:

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/659fe584-68e6-46bf-bd13-12653ef60268

CNCF Landscape

UX / UI Improvements II

  • Description: With your collaboration, we aim to analyze findings and meaningful information (quantitative and qualitative data) and run a series of ideation rounds. We will create user personas, empathy maps, and other UX deliverables that will be the foundation to lay out a set of solutions to improve the current way to search, navigate and find relevant information on the Landscape.
  • Expected Outcome: Creation user personas, empathy maps, and other UX deliverables.
  • Recommended Skills: UX reaserach, desighn thinking, Figma and prototyping.
  • Mentors: Andrea Velázquez @andreuxxxx [email protected], Nate W. @nate-double-u [email protected], Chris Aniszczyk @caniszczyk [email protected]
  • Upstream Issue: cncf/landscape#2467
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c45cc842-278f-4663-9ff4-deecc3fc040d

CoreDNS

Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support

Jaeger

Upgrade Jaeger's internal telemetry to OpenTelemetry

  • Description: historically, the Jaeger backend used the OpenTracing API, with Jaeger's own Go SDK jaeger-client-go, for instrumenting its own internals for distributed tracing. Since Jaeger's SDKs have been deprecated, we want to upgrade the Jaeger backend to use the OpenTelemetry tracing API and SDK directly.
  • Expected Outcome:
    • Replace the use of OpenTracing API with OpenTelemetry
    • Remove jaeger-client-go and jaeger-lib as dependencies
    • Remove opentracing-go and opentracing-contrib/* as dependencies
    • Switch to standard instrumentation libraries where available (e.g. for HTTP, gRPC)
    • Rethink/rework crossdock integration tests to test end-to-end flow with OpenTelemetry data
    • Publish a blog post on medium.com/jaegertracing documenting the experience
  • Recommended Skills: Go
  • Mentor(s): Yuri Shkuro (@yurishkuro, [email protected]); Albert Teoh (@albertteoh, [email protected])
  • Upstream Issue: jaegertracing/jaeger#3381
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b8009398-1252-4f63-82fe-363846ccc11d

Implement Critical Path analysis

  • Description: Jaeger (https://jaegertracing.io) is a popular platform for distributed tracing. Critical path analysis is an important tool in the latency investigations. This project aims to add support for critical path analysis to Jaeger UI.
  • Expected outcomes:
    • Implement critical path determination algorithm (maybe in the backend)
    • Enhance Trace Timeline view to overlay critical path on top of the trace.
    • Add relevant documentation to the Jaeger website
    • Author a blog post on Jaeger blog explaining the new feature
  • Stretch goals:
    • Add critical path visualization to other trace views (graph, table, flamechart)
  • Recommended Skills: Javascript, Typescript, Go
  • Mentor(s): Yuri Shkuro (@yurishkuro, [email protected]), Yash Sharma ([email protected])
  • Upstream Issue (URL): jaegertracing/jaeger-ui#1288
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0fc6c44b-5ddf-467f-8016-72cc35b4e3ff

Knative

Self-Balancing Knative Kafka Broker partitions

  • Description: Creating a Knative Kafka Broker requires developers to specify the number of partitions the backing Kafka topic should have, however, this is not an easy decision to make and it requires planning based on the expected load the Knative Broker could receive. This project aims to remove this configuration setting by having an autoscaler that is responsible to add or remove partitions based on the effective load the Knative Kafka Broker receives while preserving ordered and unordered delivery features for Triggers.
  • Expected outcome: A Knative Kafka Broker can be created without setting the number of partitions and the number of partitions for a topic backing the Knative Kafka Broker increases or decreases based on the observed load received.
  • Recommended Skills: Kubernetes, Apache Kafka, Go, Java
  • Mentor(s): Pierangelo Di Pilato @pierDipi (pierdipi AT redhat DOT com), Ali Ok @aliok (aliok AT redhat DOT com)
  • Upstream Issue (URL): knative-extensions/eventing-kafka-broker#2917
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ac483209-2b08-4f74-aaa5-4ab3203b0677

Porting Knative Serving to Microshift

  • Description: More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run in a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see Microshift used as the base platform. Knative consists of Serving and Eventing modules but focusing on Knative Serving as a first step should be more approachable. The project consists of 2 stages. First one is to run Knative on Microshift with minimal resources. This requires finding out problems here, solving them. A stretch goal is to find out what happens with architectures other than x86_64.
  • Expected outcome: Having Knative Serving with an ingress layer running on top of Microshift. Having a Hello-World Knative Service running on top. Finding issues blocking the edge setup, and possibly fixing them.
  • Recommended Skills: Golang, Kubernetes, Knative, good understanding of networking, good understanding of CI/CD
  • Mentor(s): Reto Lehmann @ReToCode (rlehmann AT redhat DOT com), Stavros Kontopoulos @skonto (skontopo AT redhat DOT com)
  • Upstream Issue (URL): knative/serving#12718
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/830eb064-cf8a-4a8e-bba3-97d429a6ca79

Konveyor

Add Integration test suite and components testing to Konveyor

  • Description: The Konveyor project helps modernize applications by providing open source tools to rehost, replatform, and refactor applications to Kubernetes and cloud-native technologies.We’re looking for help on building integration tests on application level as well as work on missing parts of Konveyor component tests.There is open testing work to better applications analysis, tasks coverage, more detailed Hub API tests and Hub integration with addons. All of those use the Hub API that is covered with basic tests already. Based on existing Hub API tests, it is expected to continue work to cover more Konveyor functionality with tests. The development environment is based on golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems.
  • Expected Outcome:
    • Integration test suite and components testing added to existing Konveyor upstream automated test suite
  • Recommended Skills:
    • Go
    • Basic software development skills (command line, git)
  • Mentor(s):
  • Upstream Issue:
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/78852896-9785-4156-bb9b-bc3c5cb6ed17

KubeArmor

Implement DNS visibility with KubeArmor

  • Description: The project aims to provide better visibility into the domains accessed from pods, with a focus on identifying and containing attacks that use techniques like Domain Generation Algorithms (DGA) to connect to remote command and control (C&C) servers. By gathering information on which domains are being accessed and applying network rules to allow only specific domains, the project aims to empower security operations (secops) teams to better prevent and respond to such attacks.
  • Expected Outcome:
    • KubeArmor to emit telemetry events for any DNS lookups from any pods.
    • Ability to see egress DNS lookups done from any pods using karmor summary.
    • Documentation
  • Recommended Skills: Go, K8s, familiarity with network security and a basic understanding of KubeArmor is a plus.
  • Mentors:
  • Upstream Issue: Issue #1219

Manage KubeArmor policies using OCI registry and use OCI hooks for container events

  • Description: The feature aims to manage KubeArmor policies using OCI registry and use OCI hooks to get container events. Currently, KubeArmor uses a UNIX domain socket file to watch for container events, but the proposed feature aims to use OCI hooks instead.
  • Expected Outcome: To provide a more secure and efficient way of managing KubeArmor policies by leveraging OCI registry. Storing policies in OCI registries will make it easier to distribute policies across multiple clusters and environments. Using OCI hooks will also reduce the overhead of monitoring container events and make it easier to integrate KubeArmor with other container runtimes.
  • Recommended Skills: Go, K8s, understanding of the Open Container Initiative (OCI) and container runtimes.
  • Mentors:
  • Upstream Issue: Issue #1130

Kubescape

Store Kubescape configuration scan results as CRs

  • Description: Kubescape is a utility that can scan a Kubernetes cluster and report on its security posture. There is an "operator" which can be installed in the cluster to perform scheduled scans scan, but this is largely used to send the data to an external service. In this project, you will implement a mechanism in the Kubescape operator to save scan results locally in a custom resource (CR), as well as a watch so that scans can be performed on cluster state changes.
  • Expected Outcome: Having the ability to scan a cluster when it changes, and have the results saved inside the cluster. This will allow users and automations to judge the security posture of changes that are made to the cluster (for example, deployments or rollouts.)
  • Recommended Skills: Go
  • Mentors:
    • Ben Hirschberg (@slashben, ben AT armosec.io)
    • Craig Box (@craigbox, craigb AT armosec.io)
    • David Wertenteil (@dwertent, dwertent AT armosec.io)
  • Upstream Issue: kubescape/kubescape#1225
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1a6a7aaf-7436-431b-9131-9422e4b2fb71

Prometheus exporter for image vulnerabilities

  • Description: Kubescape has a component that runs in-cluster which performs image scanning on all the container images deployed to a cluster. This function is largely used to send the data to an external service. In this projet, you will develop a Prometheus exporter for the image vulnerability information produced by Kubescape. This will allow users to access the data from within the cluster, as well as use it for alerting.
  • Expected Outcome: Access to cluster vulnerability data through Prometheus. For example, you should have the ability to alert on number or percentage of "Critical" level vulnerabilities in containers running in the cluster.
  • Recommended Skills: Go, Prometheus
  • Mentors:
    • Ben Hirschberg (@slashben, ben AT armosec.io)
    • Craig Box (@craigbox, craigb AT armosec.io)
    • David Wertenteil (@dwertent, dwertent AT armosec.io)
  • Upstream Issue: kubescape/kubescape#1226
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c701687-7cde-42fc-8195-08d35fdb5ee8

Vulnerability-based Dockerfile generator

  • Description: Kubescape can detect vulnerabilities in a container image. Some can automatically be remediated by changing the base image version (or other package information) inside the Dockerfile which created the image. This project is to automate this remediation.
  • Expected Outcome: An enhancement to Kubescape to generate a Dockerfile that proposes fixes for vulnerabilities found in a container image. This may be by integration with existing open source tools or developing something new.
  • Recommended Skills: Go
  • Mentors:
    • Ben Hirschberg (@slashben, ben AT armosec.io)
    • Craig Box (@craigbox, craigb AT armosec.io)
    • David Wertenteil (@dwertent, dwertent AT armosec.io)
  • Upstream Issue: kubescape/kubescape#1227
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fbaf3d52-77ee-469c-8eb4-3e0378896159

KubeVela

Expand multiple database drivers for the API server

Auto-generate the TypeScript and Java languages API SDK

  • Description: The VelaUX API server follows the Open API schema. It could auto-generate the swagger configs via CLI. When VelaUX frontend or other projects need to call these API, they must write the model code and request the API code. We can provide SDK for them to start faster. OpenAPI generator could help to generate most codes. But there are still some special cases like:
    • Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE.
    • Automatically handles the user authentication process, including automatically refreshing tokens.
    • The API definition may be incomplete accuracy, we should check it to generate high-quality code.
  • Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server:
    • VelaUX APIServer TypeScript SDK
    • VelaUX APIServer Java SDK
  • Recommended Skills:
    • Golang
    • Kubernetes
    • Backend APIs Development
    • OpenAPI schema
    • CUE
  • Mentor(s):
  • Upstream Issue (URL): kubevela/kubevela#5428
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b97b2f2d-4dbd-45f5-9121-0e865aa6dfd9

Kyverno

Kuttl tests for the Kyverno policy library

  • Description: Kyverno has the largest policy library of any policy tool for Kubernetes. Ensuring that policies work effectively across releases of both Kyverno and Kubernetes is important for users. Additionally, these tests can be leveraged in the CI processes ensuring that changes to the Kyverno codebase do not cause regressions which impact areas relevant to these policies. In this mentorship, you will learn how the kuttl tool works and write test cases using kuttl to cover all policies in the official Kyverno policy library.
  • Expected outcome: All policies have corresponding tests using the kuttl tool.
  • Recommended Skills: Kubernetes, Kyverno
  • Mentor(s): Chip Zoller @chipzoller (chipzoller AT gmail DOT com)
  • Upstream Issue (URL): kyverno/policies#546
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/85ebe560-e9ee-42fe-9dff-f8dc6a11ef27

Sigstore Cosign Updates

  • Description: Kyverno supports image signature and attestation verification using the Sigstore Cosign tooling. Re-implement the Kyverno Sigstore Cosign module to use OCI artifacts and references and remove dependencies to the Cosign CLI packages.
  • Expected outcome: Kyverno can use OCI artifacts to verify container images that are in Cosign format.
  • Recommended Skills: Golang, Kubernetes, Kyverno
  • Mentor(s):
    • Shuting Zhao @realshuting (shuting AT nirmata DOT com)
    • Vishal Choudhary @Vishal-Chdhry (contactvishaltech AT gmail DOT com)
  • Upstream Issue (URL): kyverno/kyverno#7087
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cabb007c-5669-4b16-8778-36d995a71591

ValidatingAdmissionPolicy support, Phase 2

  • Description: Kyverno is working towards support of ValidatingAdmissionPolicy (CEL admission). Extend this support for other items such as CLI, reporting, and auto-generating ValidatingAdmissionPolicies from Kyverno policies.
  • Expected outcome: Extended support and integration with ValidatingAdmissionPolicies
  • Recommended Skills: Golang, Kubernetes, Kyverno
  • Mentor(s):
    • Jim Bugwadia @jimbugwadia (jim AT nirmata DOT com)
    • Mariam Fahmy @MariamFahmy98 (mariamfahmy66 AT gmail DOT com)
  • Upstream Issue (URL): kyverno/kyverno#7088
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e4be265d-fa05-46b7-8fad-2585b6a76082

Cleanup Policies, Phase 2

LitmusChaos

Enhance/improve chaos center code base and redesign chaos workflow apis

  • Description: This project focuses on enhancing and improving the Chaos Center code base, specifically redesigning the Chaos Workflow APIs to provide an enhanced user experience. The main objectives include refining the functionality of the Chaos Workflow and Workflow Run APIs, modularizing the chaos-workflow package into separate packages, and addressing security vulnerabilities and golangci-lint issues in the Chaos Center backend components. The project aims to deliver a more robust and secure Chaos Center platform, offering improved usability and performance for users.
  • Expected outcome: The outcome of this project will be improved functionality, security, and usability of the chaos workflow APIs and chaos-center backend components through the implementation of new features, refactoring of existing code, and addressing of security vulnerabilities.
  • Recommended Skills:
    • Golang
    • Kubernetes
    • Backend APIs Development
  • Mentor(s):
  • Upstream Issue (URL): litmuschaos/litmus#3970
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/983193ea-9cca-405f-baa5-e6ade4df1ba2

Enhance/Upgrade chaos operator and chaos exporter module

  • Description: LitmusChaos is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project idea involves upgrading the Chaos Operator and Chaos Exporter repositories by updating their dependencies, addressing security vulnerabilities, and adding new functionality. Specifically, the project aims to upgrade the operator-sdk and Prometheus exporter versions, add new Prometheus metrics to the Chaos Exporter, and fix security vulnerabilities pointed out by trivy and golangci-lint. Furthermore, the project seeks to add unit test cases to both repositories to ensure that their functionality is robust and reliable. Overall, this project aims to improve the stability, security, and functionality of the Chaos Operator and Chaos Exporter repositories, making them better suited for use in production environments.
  • Expected outcome: The outcome of this project will be improved stability, security, and functionality of the Chaos Operator and Chaos Exporter modules through the upgrade of dependencies, addition of new metrics, and implementation of unit tests.
  • Recommended Skills:
    • Golang
    • Kubernetes and k8s golang client
    • Prometheus
  • Mentor(s):
  • Upstream Issue (URL): litmuschaos/litmus#3969
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bd6e875a-a64c-4405-af1c-677d8c45014b

Meshery

Meshery UI Permissions Framework

  • Description: Meshery UI lacks a permissions framework. The existing internal implementation is simple, fragile and must be completely rewritten. The approach to implemention a permmissions framework includes using React.js and CASL.js. Meshery UI's approach needs to be extensible given that this framework will be an extension point for Remote Providers to supply their own permissions.
  • Expected outcome: Definition of permissions and their enforcement in Meshery with an aim for deep granularity and extensibility with each user interface input component carrying a unique permission key id. Each key is then put into a group of keys in a keychain, keychains assigned to user roles, in turn, roles assigned to users. With users having the ability to create own custom roles, the framework will be dynamic based on the associated server-side permissions for the currently auth’ed user.
  • Recommended Skills: React.js, CASL.js
  • Mentor(s): Lee Calcote @leecalcote ([email protected]), Abhishek Kumar @Abhishek-kumar09 ([email protected])
  • Upstream Issue (URL): meshery/meshery#7436, meshery/meshery#7382
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f4a9804f-2e46-42a4-b2ae-ad3ea7b29734

OPA policy evaluation in-browser using WebAssembly and Rego

Adopt OCI as the packaging and distribution format for Meshery MeshModels

  • Description: Meshery MeshModels represent a schema-based description of cloud native infratructure. MeshModels need to be portable between Meshery deployments as well as easily versionable in external repositories.
  • Expected outcome:
    • Meshery clients (mesheryctl and Meshery UI) should be able to import/export MeshModels as OCI images.
    • Meshery clients (mesheryctl and Meshery UI) should be able to push/pull from OCI-compatible registries.
    • Stretch Goal: OCI image signing; Verify the authenticity of MeshModels using cosign.
    • Target registries: Meshery Catalog (https://meshery.io/catalog), Artifact Hub.
  • Recommended Skills: Reactjs, Golang, GraphQL
  • Mentor(s): Lee Calcote @leecalcote ([email protected])
  • Upstream Issue (URL): meshery/meshery#6447
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/26377c30-9ffd-41e3-bfea-839bf126f8f6

OCI compatible Kubernetes ontology

  • 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):

  • MeshModel capabilities browser

  • Import/export of MeshModel models and components as OCI images

  • augmentation of cuelang-based component generator

  • Recommended Skills: cuelang, golang, OCI

  • Mentor(s): Lee Calcote (@leecalcote, [email protected])

  • Issue: cncf/tag-network#24

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bb8ddf84-31d7-4a89-9e4b-e6aa9601c0db

Notary

Design and implement the new Notary website

  • Description: Design the new Notary website using the Figma tool and develop it based on the design layout. We redesigned the Notary website and finished the first phase development work with CNCF employee @thisisobate in #PR 139. This project is to continue to design and implement the new Notary website and ensure deliver a developer-friendly experience.
  • Expected Outcome:
    • Design and implement the Adopters page
    • Redesign a Community page
    • Improve the landing page design; add an installation section with a terminal effect design
    • Support mobile responsive design
    • Add a pop-up window on the landing page to tell users how to join the community
    • Add Algolia search for the website
    • Design and implement a video page to list Youtube videos
    • Refine the content on the website
    • Add Broken link check to Netlify CI
  • Recommended Skills: Figma design, HTML, CSS, JavaScript, Hugo
  • Mentor(s): Feynman Zhou (@FeynmanZhou , [email protected])
  • Upstream Issue (URL): notaryproject/notaryproject.dev#194
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06774504-da91-469e-89f9-14fb18b6e0d8

Develop content for Notary documentation and blogs

  • Description: Develop content for Notary documentation and write blog posts to educate users about the Notary use cases. Write user guides, contributing guides, and developer guides for every new Notary release and keep those content up-to-date.
  • Expected Outcome:
    • Write user guides with end-to-end scenarios based on given doc structure and requirement
    • Write contributing guides and developer guides, ensure new developers can easily build and start contributing to Notary subprojects
    • Write blog posts to educate users to use Notation with cloud-native ecosystem tools
  • Recommended Skills: OCI, Docker, Kubernetes, Notary, Git, Markdown, Technical writing experience
  • Mentor(s): Mentor(s): Yi Zha, @yizha1 ([email protected])
  • Upstream Issue (URL): notaryproject/notaryproject.dev#195
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/007ca3e9-c121-4428-8e63-57bc0418e98a

ORAS

Design and implement Artifact Explore web portal

  • Description: This project goal is to improve the efficiency of the image developers and users through the artifact explorer tool with ORAS under the hood. This tool helps users to explore and search the content of an artifact or a registry. This doc is to gather ideas for early brainstorming purposes. For users, this tool reduces CLI learning cost and improve efficiency for developers. They don’t need to memorize and type the CLI commands to explore the content of an OCI artifact and registry.

  • Expected Outcome:

    • Provides a web portal to view the content of OCI artifacts from any public registries
    • Users can drill down into the detailed content of an image manifest or a layer
    • Users can view the artifact reference graph from the web portal
    • Users can view and download the supply chain artifacts like the signature, SBOM, attestation
    • Provides search capabilities to allow users to search container images or OCI artifacts on a central web portal. We can combine it with Artifact Search API capabilities.
    • Explore the image’s file system of layer (tentative)

  • Recommended Skills: Figma design, HTML, CSS, JavaScript, Hugo, Docker

  • Mentor(s): Feynman Zhou (@FeynmanZhou , [email protected]), Billy Zha (@qweeah , [email protected]), Asmit Malakannawar (@asmitbm , [email protected])

  • Upstream issue: oras-project/oras-www#158

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9749bc0a-04c9-498d-a16c-e66c0930e819

Refactor the ORAS documentation structure and write new user guides

Service Mesh Performance

Service Mesh Performance IDE Plugin

  • Description: The objective of this project is to develop IDE plugins that can enhance the developer experience while working with Service Mesh Performance Performance Profiles. The proposed plugins will leverage technologies such as golang and cuelang to provide features such as syntax highlighting, auto-completion, validation, and rendering previews for Service Mesh Performance profile and model definitions.
  • Expected outcome:
    1. Release VS Code Extension
    1. Syntax Highlighting and Auto-completion: The plugin can fetch SMP Model definitions such as cloud-native components and their relationships. This information can be used to provide syntax highlighting and auto-completion for these definitions in the JSON files, making it easier for developers to write error-free code.
    1. Validation and Reference: For Meshery MeshModel definitions such as cloud-native components and their relationships, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also fetch the SMP Model schemas and display them in the IDE for reference.
  • Recommended Skills: Cuelang
  • Mentor(s): Lee Calcote @leecalcote ([email protected]), Xin Huang @gyohuangxin ([email protected])
  • Upstream Issue (URL): service-mesh-performance/service-mesh-performance#379
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4735d0fa-229f-43e7-9415-dff9220bf687

Strimzi

Proof of Concept of an MQTT to Apache Kafka bridge for producing messages

  • Description: A really common use case we have been seeing is about enabling an IoT scenario with MQTT based devices and using an Apache Kafka cluster as the events and storage platform running on Kubernetes via Strimzi. In order to do that, there is the need to map the MQTT protocol to the custom Apache Kafka one and bridge from one to the other. This project idea is about designing such a mapping and developing a pure Netty based MQTT server component (not a full MQTT broker) able to accept MQTT client connections and handling the corresponding communication based on the MQTT 3.1.1 specification. Finally, developing the Kafka producer part to get messages from MQTT clients and sending them to an Apache Kafka cluster.
  • Expected outcome: POC source code for an MQTT to Apache Kafka bridge
  • Recommended Skills:
    • Java
    • Apache Kafka (not mandatory but to be learned)
    • MQTT protocol (not mandatory but to be learned)
  • Mentor(s):
  • Upstream Issue (URL): strimzi/strimzi-kafka-operator#8030
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8d301adf-94d8-4e5d-821d-f904ed15c3f9

Thanos

Continuation of add query observability for the new engine

Vitess

Rework the frontend UI of Vitess’ benchmarking tools

  • Description: Vitess uses a couple of tools to benchmark its codebase and to make sure that new code doesn’t introduce performance regressions. These tools are: arewefastyet and the VReplication Benchmarking Framework. We currently have an old frontend UI that serves arewefastyet. However, this UI is slow, not optimized and not easily extensible. It uses the built-in Golang template system to serve pages. We would like to create a common frontend UI that will be used by both benchmarking tools and that will replace the current arewefastyet’s UI. The mentee will have the responsibility of creating the UI using (most likely) React/Vite on Vercel. The frontend component will connect to our already-existing backend components: a MySQL database and arewefastyet’s REST API.

  • Expected Outcome: The expected outcome is to have a working frontend UI that integrates well with our different backends (databases and benchmarking tools’ APIs).

  • Recommended Skills: React, Vercel, Vite, REST API, (Optional writing APIs in Golang)

  • Mentor(s):

  • Upstream Issue (URL): vitessio/arewefastyet#328

  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8299d27a-9e36-4de6-abbc-c9282634ee03

WasmEdge

Serialization Completion

  • Description: WasmEdge is a WebAssembly runtime in both interpreter and ahead-of-time mode. However, WasmEdge only supports the binary format for the input WebAssembly file. To help the text format WebAssembly loader feature in the future, the implementation of serializing a WebAssembly module is necessary. In this mentorship, we hope the mentee should complete the serialization functions already in the dev/serialize branch of the WasmEdge repo.
  • Expected outcome: Complete the serialization functions of WebAssembly modules, such as the element segment and data segment encoding. Complete the WebAssembly instructions encoding. Generate the unit test data and pass the unit tests. >80% of code coverage for serialization.
  • Recommended Skills: C/C++, WebAssembly
  • Mentor(s): Yi-Ying He @q82419 (yiying at secondstate dot io), Hung-Ying Tai @hydai (hydai at secondstate dot io)
  • Upstream Issue: WasmEdge/WasmEdge#2262
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4a8a4f26-0ca9-4517-8cce-582c92092e33

zlib Plugin Support

Support Tensorflow and PyTorch in WasmEdge’s Python runtime

  • Description: In this project, you will incorporate WasmEdge’s NN (Neural Network) extensions into the Python interpreter. WasmEdge provides C and Rust APIs for guest applications to access host functions in the underlying Tensorflow and PyTorch libraries. You will make those functions accessible from the CPython-based interpreter as Python wrappers. This way, Python applications can do lightweight AI inference on the WasmEdge container.
  • Expected outcome:
    • Investigate and list all C-based host function APIs for Tensorflow and PyTorch inference in WasmEdge NN.
    • Create CPython wrappers for those host functions.
    • Create high-level Python wrapper functions that are ergonomic for Python developers.
    • Create CI and demo apps to validate the Python wrapper API.
    • Create detailed documentation and tutorials.
  • Recommended Skills: Proficient in C programming including creating dynamic libraries; Proficient in Python and machine learning programming. Basic understanding of WebAssembly and WasmEdge.
  • Mentor(s): Michael Yuan @juntao (michael at secondstate dot io), Asen Alexandrov @adalexandrov (alexandrov at vmware dot com)
  • Upstream Issue: WasmEdge/WasmEdge#2471
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/884ff3f2-3ea3-4010-8928-ca27bbae219a

A stream log processing framework for WasmEdge

  • Description: In this project, we aim to build a Rust-based log processing framework. Applications built on this framework will be compiled into WebAssembly and run in WasmEdge containers side by side with Linux containers and apps. The WasmEdge app collects logs from other containerized apps and then sends them to a streaming database or processing pipeline.
  • Expected outcome:
    • Create a Rust framework with 3 traits similar to the Transformer trait in the MEGA framework.
      • The Collector trait abstracts operations needed for a log collector.
      • The Transformer trait abstracts the transformation algorithms that can be applied to the logs.
      • The Destination trait abstracts operations needed to send transformed to a streaming data pipeline or database.
    • Implement at least two Collectors. One for MySQL database binlog and the other for a generic log file in a Linux container in the same Kubernetes pod.
    • Implement at least two Transformer algorithms supported by FileBeat.
    • Implement at least three Destinations. One for a Kafka queue, one for a Redis database, and the other for ElasticSearch.
    • Provide CI and demo test cases.
    • Provide documentation and tutorials.
  • Recommended Skills: Proficient in the Rust programming language; Familiarity with MySQL, Kafka, ElasticSearch, and FileBeat; Familiarity with Kubernetes and related container management tools; Basic understanding of WebAssembly and WasmEdge
  • Mentor(s): Michael Yuan @juntao (michael at secondstate dot io)
  • Upstream Issue: WasmEdge/WasmEdge#2470
  • LFX URL: https://mentorship.lfx.linuxfoundation.org/project/55c226fe-d119-4b2c-aba0-e7415867f6e5