Skip to content

Latest commit

 

History

History
332 lines (261 loc) · 28.3 KB

2024.md

File metadata and controls

332 lines (261 loc) · 28.3 KB
Raw

Project Ideas

If you are a project maintainer and consider mentoring during the GSoC 2024 cycle, please, submit your ideas below using the template.

Google summer of code timeline.

You can find the project ideas from previous year here.

NOTE: Please note that GSoC is a program known for its strict deadlines. In addition to responding to your mentee on time, you will be required to submit evaluations on time. Failures to meet the deadlines might affect CNCF's future participation in GSoC.

Template

#### CNCF Project Name

##### Project Title

- Description:
- Expected Outcome:
- Recommended Skills:
- Expected project size: # one of small (~90 hour projects), medium (~175 hour projects) and large (~350 hour projects)
- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.
  - Jane Doe (@jane-github, jane@email.address) - primary
  - John Doe (@john-github, john@email.address)
- Upstream Issue (URL):

Proposals

CNCF GOSST

CNCF and Google Open Source Security Team GSoC Collaboration - Enhancing Security Across CNCF Ecosystem
  • Description: This project is a collaborative effort between the CNCF and Google's Open Source Security Team to improve security practices across various CNCF projects. The focus is identifying and addressing security vulnerabilities, integrating security tools like OSS-Fuzz, and enhancing build and release security processes. The goal is to get all CNCF projects to use scorecards (focusing on graduated/incubating projects first) and to remediate some of the findings.
  • Expected Outcome:
    • All graduated and incubating CNCF projects using OpenSSF Scorecards to assess and enhance their security postures. Stretch goal: all (including sandbox) CNCF projects using OpenSFF Scorecards.
    • Integration or enhancement of fuzzing with OSS-Fuzz for CNCF projects
    • Improved build/release security by automating builds and releases, added build provenance, signing, and improved reproducibility
  • Recommended Skills: Security analysis, CI/CD practices, programming (preferably Go), knowledge of CNCF projects.
  • Expected project size: large (~350 hour projects)
  • Mentor(s):
  • Upstream Issue (URL): #1196

Falco

Upgrading event-generator and automating Falco performance testing
  • Description: Falco is a real-time security tool designed to detect abnormal behaviours and security-related runtime events in Linux systems and the cloud. The event-generator is an utility within the Falco ecosystem that helps testing Falco’s detection capabilities. The tool also has benchmark capabilities that represent a building block of the Falco performance testing practices. However, the project received less attention than required in the past few years and would require some care and renovation. This Google Summer of Code project proposes upgrading the event-generator to improve its testing and benchmarking capabilities, its reliability, and its consistency, and developing new Continuous Integration pipelines based on it. The end goal is to evolve the event-generator and make it the standard tool for systematically assessing the correctness and performance of Falco’s threat detection capabilities at every release and development cycle
  • Expected Outcome: The project will result in an extended version of the event-generator tool that reliably generates a consistent number of events per second and stresses the most common detection scenarios of Falco. This enhanced utility will be integrated into Falco’s Continuous Integration (CI) pipeline, allowing for efficient systematic monitoring of performance regressions while ensuring alignment with past benchmarking results. Eventually, this could originate new performance optimizations in Falco itself. A stretch goal for the mentee would be to become an official maintainer of the event-generator project and/or of other repositories of the Falco ecosystem
  • Recommended Skills: Go programming language, familiarity with continuous integration, understanding of performance benchmarking concepts
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): falcosecurity/evolution#362

in-toto

Sigstore support for in-toto-jenkins
  • Description: The in-toto Jenkins plugin allows users to generate metadata in their build pipelines. Currently keys or credentials must be provided to the plugin to sign the metadata, whereas Sigstore offers keyless signing and verification. The addition of Sigstore transport will allow seamless uploading of metadata to Rekor transparency log. This project aims to enhance the Jenkins plugin by adding Sigstore support, allowing keyless signing and adding Sigstore transport.
  • Expected Outcome: in-toto-jenkins plugins gets support for Sigstore
  • Recommended Skills: Java, Jenkins
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
  • Upstream Issue (URL): in-toto/in-toto-jenkins-plugin#6
Add GUAC support
  • Description: The project aims to integrate Graph for Understanding Artifact Composition (GUAC) with in-toto, a framework safeguarding software supply chain integrity. Graph for Understanding Artifact Composition (GUAC) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them. This project seeks to extend in-toto's capabilities by incorporating GUAC, enabling users to query GUAC with Package URLs (purls) and retrieve pertinent attestations.
  • Expected Outcome: Adds functionality to query GUAC, retrieve and parse relevant attestations for the specified artifact.
  • Recommended Skills: Go, Python
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
  • Upstream Issue (URL): in-toto/attestation-verifier#29

Jaeger

Deployment options for Jaeger v2
  • Description: Jaeger is a distributed tracing platform. We are working towards Jaeger v2 that is re-architected to be a custom distribution of the OpenTelemetry Collector. There are multiple tracks towards that milestone, one of them is to address the deployment process for the end users. The project involves analysis of the existing solutions, such as Kubernetes Operators for Jaeger-v1 and OpenTelemetry Collector, deciding on the strategy for how to support deployment options for Jaeger-v2, and implementing + documenting them.
  • Expected Outcome:
    • Support deploying Jaeger v2 via Kubernetes Operator, Helm chart, and brew.
    • Documentation on the website.
  • Recommended Skills: Go, Kubernetes, scripting, CI/CD
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): jaegertracing/jaeger#5221

Keptn

GitHub issue self-assignment bot
  • Description: The goal is to create a self-service issue assignment bot for GitHub contributors who are not yet part of the organization but would like to work on issues marked for external handling. The bot should be able to check if the user is part of the organization, examine if the pre-conditions for self-assignment are met (configurable labels or rules about number of issues already assigned/PRs opened), and assign the issue. Additionally, the bot should be able to track the state of the issue by adding/removing specific labels. The bot should be part of the CI and executed as an action on an issue change.
  • Expected Outcome:
    • Implement GitHub bot in TypeScript/Golang
    • Bot does not require an external hosting
    • Bot is able to assign GitHub issues to contributors following the pre-defined set of rules
    • Bot is able to track the status of GitHub issues with labels
    • Introduce documentation about how to use and configure the bot
  • Recommended Skills: GitHub API, TypeScript/Golang, Webhooks
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): keptn/lifecycle-toolkit#2823

Knative

Improving Wasm support in Knative Functions
  • Description: Wasm aka WebAssembly provides a portable binary-code format that is ideal to write small functions. However, current support for Wasm in Knative Functions is limited and slow. This project will improve this support.
  • Expected Outcome: Contribute Wasm support to Knative functions, documentation, sample code etc. Ideal outcome would be running Wasm code via Knative Functions in a convenient way. However, there are some unknowns. Other possible outcome could be identifying the roadblocks and possible improvements
  • Recommended Skills: basic programming skills, use IDE and debugger, some experience with Kubernetes
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
    • Aleksander Slominski @aslom (aslomins AT redhat DOT com) - primary
    • Matthias Wessendorf @matzew (matzew AT redhat DOT com)
    • Luke Kingland @lkingland (lkingland AT redhat DOT com)
  • Upstream Issue (URL): knative/func#2151

KubeArmor

Rancher Plugin Integration
  • Description: The goal is to create an extension for Rancher, a Kubernetes management platform, which will enable interaction with KubeArmor. The extension will have the capability to install KubeArmor, allow the users to easily see the state and manage KubeArmor policies, default posture, protected containers, and provide monitoring of workload behavior through alerts and telemetry.
  • Expected Outcome: Rancher plugin address the following points:
    • Install KubeArmor
    • Manage KubeArmor Security Policy Resources
    • Manage ClusterWide and Namespace Specific KubeArmor Configuration and Security Postures (Policy Decision and Visibility)
    • Handle Recommendation of Policies based on karmor recommend
    • Integrate KubeArmor Visibility Dashboards based on Grafana with Rancher Preset Grafana Dashboards
  • Recommended Skills: Rancher, Grafana stack, Javascript
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue: kubearmor/KubeArmor#992
Automating Benchmarking Workflow

  • Description: This project aims to develop an automated benchmarking system for KubeArmor. The focus will be to enhance the efficiency and repeatability of performance evaluations, which are currently being done manually. The benchmarking system will streamline the process across various scenarios, ensuring that KubeArmor’s performance is consistently and rigorously evaluated after each release. The task would include Automate the execution of benchmarks under various scenarios, Metrics Collection and reporting it through appropriate channel(slack, or updating readme) after every release.

  • Expected Outcome:

    • A fully automated benchmarking system that can reliably assess the performance of KubeArmor across various scenarios.

  • Recommended Skills: Go programming language, understanding of how CI concepts continuous integration

  • Expected project size: Large (350 hour project)

  • Mentor(s):

  • Upstream Issue: kubearmor/KubeArmor#1669

Kubernetes Gateway API

Design and develop notification mechanism for ingress2gateway.
  • Description: Gateway API is the new generation of Kubernetes Networking APIs. Ingress2gateway is a tool to help users migrate and convert Ingress, and implementation-specific configurations to Gateway API. As we add more conversion logic, and onboard more implementations (essentially Ingress and Gateway controllers like Istio, Kong, etc.), logs become insufficient to report conversion results, warnings and crucial messages regarding the conversion. To improve the tool usability, we need to enable users to know exactly the original resource/s -> new resource/s mapping, PLUS what the tool couldn't convert so they could make the final touches before applying the new resources to the cluster. A few of the notification types we'll need to support:
    • Overview of original resources and the equivalent resources to which they have been converted
    • Warnings about partial conversions (partial fields within a resource)
    • Warnings about fields/logics not supported in Gateway API
  • Expected Outcome: A new notification mechanism to notify users conversion results, warnings and crucial messages regarding their conversion has been added and is being used across implementations supported by the tool.
  • Recommended Skills: Go, Kubernetes
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
    • (Lior Lieberman, @LiorLieberman)
    • (Mattia Lavacca, @mlavacca)
  • Upstream Issue: kubernetes-sigs/ingress2gateway#131

LitmusChaos

Integration of Fuzzing Test Suites for LitmusChaos(ChaosCenter) with OSS-FUZZ
  • Description: This task aims to implement comprehensive fuzzing test suites for our GraphQL interface and Authentication server (ChaosCenter) to identify vulnerabilities and ensure robustness. The process involves developing targeted fuzzing strategies to thoroughly test these components and integrating the tests with OSS-FUZZ for automated fuzzing. This integration should streamline the process of monitoring and addressing potential security issues. The task also includes making the results accessible through the ClusterFuzz Dashboard for efficient management and analysis
  • Expected Outcome:
    • Comprehensive fuzzing test suites for the GraphQL interface and Authentication server are developed and demonstrate good coverage of the codebase.
    • Successful integration with OSS-FUZZ, ensuring that fuzzing tests are automatically run and their outcomes are reported.
    • All test results, including coverage statistics, vulnerabilities, and crash reports, are visible and manageable through the ClusterFuzz Dashboard.
    • Documentation on how to maintain and extend the fuzzing tests as the project evolves.
  • Recommended Skills: Golang, Kubernetes
  • Expected project size: Large (350 hour project)
  • Mentors(s):
  • Upstream Issue (URL): litmuschaos/litmus#4425

Meshery

Understanding and Codifying the Relationships between Kubernetes Resources
  • Description: 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.
  • Expected Outcome: YAML-formatted definition
  • Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue: meshery/meshery#10264

Prometheus

Add Created Timestamp to Prometheus/OpenMetrics Text Format
  • Description: Created Timestamp was added to Prometheus protobuf format and storage in 2023 GSoC in the summer. The important follow up was to add optional created timestamp feature to Prometheus or OpenMetrics Text formats, similar to prometheus/proposals#32. This project will involve proposal and implementation of the design that would be accepted by Prometheus community. The change has to be carefully designed as the scrape text formats are the most commonly used "APIs" for pulling (scraping) metrics in the CNCF generally. NOTE: No need to carefully prepare design upfront, we will do the proper design together.
  • Expected Outcome: Prometheus or OpenMetrics Text format have support for created timestamp (for OpenMetrics it means replacing the current design that inolves extra series, which can be problematic) e.g. in metadata or similar to exemplar.
  • Recommended Skills: HTTP, Go, defining stable APIs
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
  • Upstream Issue (URL): prometheus/prometheus#13537
Move out of gogo/protobuf to protobuf with vtproto implementation
  • Description: Prometheus, like many other Go projects, still use "gogo" (https://github.com/gogo/protobuf) implementation of the protobuf generator, which was deprecated a while ago. Since then protobuf projects moved forward with the new API version and various amazing protobuf plugins in the community like "vtproto" (https://github.com/planetscale/vtprotobuf) from Vitess. In Prometheus we use protobuf mainly for remote writing, as well as protobuf scraping protocols. In both cases the efficiency of the solution is critical. This is why gogo implementation was popular--it allowed a certain "nullable" option, that reduced amount of pointers in generated structures and instead preferred allocating bigger amount of memory at once (e.g. []*CustomType was in gogo []CustomType). Long story short, moving Prometheus out of gogo protobuf to native Go protobuf with vtproto has to happen due to lack of support for gogo for new protobuf API iterations. However, it not only requires code changes, but also carefully benchmarking and optimizing for different generated message structures (allocating smaller objects, but more of them). If you want to dive into amazing world of coding optimizations and benchmarks -- this project is for you! NOTE: No need to carefully prepare design upfront, we will do the proper design together.
  • Expected Outcome: Prometheus project does not depend on gogo protobuf and its performance (e.g. scraping and remote write) is not worse than what we have now with gogo.
  • Recommended Skills: Go, protobuf, benchmarking
  • Expected project size: Medium (175 hour project)
  • Mentor(s):
  • Upstream Issue (URL): prometheus/prometheus#11908

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
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): service-mesh-performance/service-mesh-performance#379

WasmEdge

Implementing Coredump for Post-Mortem Debugging in WebAssembly
  • Description: This project, wasm-coredump, aims to enhance the debugging capabilities of WebAssembly by implementing a coredump feature for post-mortem analysis. When WebAssembly encounters a runtime error, it will initiate a process to collect debugging information, including stack frames, local variable values, and a snapshot of the linear memory. This data is saved in a coredump file, which, along with DWARF information, can be analyzed post-mortem to debug the error. The project involves creating or enhancing tools to generate and analyze Wasm coredumps, addressing the unique challenges of WebAssembly's memory model and execution semantics.
  • Expected Outcome:
    • A set of new API and tool options to specify the saved coredump files.
    • Implement the coredump inside the WasmEdge components, when a trap is triggered, there should be a whole process to log and save any information defined in the wasm-coredump spec.
    • The coredump file must be compatible with the current toolchain, including wasmgdb and wasm-edit.
    • Documentation on the coredump format, including how to encode process, module, and instance information.
    • Tutorials, examples, and demonstration of post-mortem debugging using the implemented coredump feature.
  • Recommended Skills: WebAssembly, C++, Debugger
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): WasmEdge/WasmEdge#3205
Enabling LLM fine tuning in the WASI-NN PyTorch plugin
  • Description: WasmEdge now offers a PyTorch inference feature through the WASI-NN proposal. As LLM (Language Model) is a highly sought-after topic, it has become essential to provide LLM fine-tuning as well. To achieve this, we plan to fine-tune the LLM model and extend the current WASI-NN spec by adding a set of extra APIs. With this plugin, application developers can develop the logic to enhance the model as per their requirements.
  • Expected Outcome:
    • Take llama2-7b as the fine-tuning target; the final implementation should handle it correctly.
    • Extend the WASI-NN spec if needed to support the fine-tuning feature.
    • Implement the fine-tuning functions inside WASI-NN PyTorch plugin.
    • Documentation, examples, tutorials, and demonstration are required.
  • Recommended Skills: C++, WebAssembly, PyTorch
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): WasmEdge/WasmEdge#3208
Enabling LLM fine tuning in the WASI-NN ggml plugin
  • Description: WasmEdge now offers an embedded llama.cpp backend via WASI-NN spec. However, we only support inference at the current stage. As LLM (Language Model) is a highly sought-after topic, it has become essential to provide LLM fine-tuning as well. To achieve this, we plan to fine-tune the LLM model and extend the current WASI-NN spec by adding a set of extra APIs. With this plugin, application developers can develop the logic to enhance the model as per their requirements.
  • Expected Outcome:
    • Take llama2-7b as the fine-tuning target; the final implementation should handle it correctly.
    • Extend the WASI-NN spec if needed to support the fine-tuning feature.
    • Implement the fine-tuning functions inside WASI-NN ggml plugin.
    • Documentation, examples, tutorials, and demonstration are required.
  • Recommended Skills: C++, WebAssembly, LLM fine-tuning
  • Expected project size: Large (350 hour project)
  • Mentor(s):
  • Upstream Issue (URL): WasmEdge/WasmEdge#3209

Open Cluster Management

Scheduling AI workload among multiple clusters

  • Description: Open Cluster Management (OCM) focuses on multicluster and multicloud management scenarios for Kubernetes applications. Open APIs are evolving within this project for cluster registration, workload distribution, dynamic placement of policies and workloads, and much more. The placement concept is used to dynamically select a set of clusters so that higher level users can either replicate Kubernetes resources to the member clusters or run their advanced workload. For example: as an application developer, I can deploy my workload to clusters with the most allocatable memory and CPU.

    Now, with the rise of AI technology, there’s a growing need to schedule AI workload based on GPU/TPU resources. In this project we want you to use the placement extensible scheduling mechanism to implement a GPU/TPU resource collector addon by addon template and provide an AddonPlacementScore to make placement decision based on GPU/TPU resources. We also want you to propose a customized external Kueue Admission Check controller to consume the placement decision to schedule AI workload among multiple clusters based on GPU/TPU resources.

  • Expected Outcome:

    • Develop the GPU/TPU resource collector addon, which includes documentation of the addon architecture and describing the AddonPlacementScore usage. Also, implement the addon using the addon template and contribute the code to the addon-contrib repository.
    • Deliver a proposal for the external Kueue Admission Check controller. The proposal should outline the API design and explain how the controller uses the OCM scheduling result and interacts with Kueue. The proposal needs to be finally reviewed in OCM community meeting. Also, you need to deliver a prototype based on the proposal.

  • Recommended Skills: Golang, Kubernetes, Scheduling

  • Expected project size: Large (350 hour project)

  • Mentor(s):

  • Upstream Issue (URL): open-cluster-management-io/ocm#369