Skip to content

Commit

Permalink
Add Knative GSoC ideas
Browse files Browse the repository at this point in the history
Signed-off-by: Ali Ok <[email protected]>
  • Loading branch information
aliok committed Jan 25, 2023
1 parent 3ede967 commit 3d97893
Showing 1 changed file with 49 additions and 0 deletions.
49 changes: 49 additions & 0 deletions summerofcode/2023.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,3 +24,52 @@ If you are a project maintainer and consider mentoring during the GSoC 2023 cycl

---

## Ideas

- [Knative](#knative)
- [Multiple Knative Eventing control planes](#multiple-knative-eventing-control-planes)
- [Eventing Sender Identity](#eventing-sender-identity)
- [NetworkPolicy support for Knative Serving](#networkpolicy-support-for-knative-serving)
- [Improving Observability in Knative Eventing](#improving-observability-in-knative-eventing)

### Knative

#### Multiple Knative Eventing control planes

- Description: We see more users asking for complete isolation in Knative Eventing deployments. While there are Knative Eventing components that support isolated data planes, we are interested in to see isolated control planes as well. There were discussions about this in the community before and many of the asks were left unadressed. However, we have tools that support multitenancy today, such as [kcp](https://github.com/kcp-dev/kcp). We see this project as an experiment.
- Expected outcome: Finding issues blocking multiple control planes, and possibly fixing them.
- Recommended Skills: Golang, Kubernetes, Knative, Kubernetes Controllers
- Mentor(s): Ali Ok @aliok
- Expected project size: 350h
- Difficulty: Hard
- Upstream Issue (URL): https://github.com/knative/eventing/issues/6601

#### Eventing Sender Identity

- Description: Leveraging Kubernetes Service Account identity and OAuth audiences, users should be able to configure Knative Eventing components to authenticate CloudEvent deliveries using the identity of the Subscription, Trigger, or Source. Additionally, Brokers and Channels can leverage the OAuth identity associated with incoming CloudEvents to implement policy.
- Expected outcome: At least the following components are able to use service accounts for authentication: in-memory-channel, multitenant broker, apiserver source, ping source. Ideally, the primitives from this project could be re-used by other channel and broker implementations.
- Recommended Skills: Golang, Kubernetes, OAuth or OIDC
- Mentor(s): Evan Anderson @evankanderson
- Expected project size: 350h
- Difficulty: Medium
- Upstream Issue (URL): https://github.com/knative/eventing/issues/5047

#### NetworkPolicy support for Knative Serving

- Description: Implement port-level network routing for Knative Serving internal addresses. This will be an extension of https://github.com/knative-sandbox/net-kourier/pull/852 to other Knative Ingress implementations, along with implementation of default NetworkPolicies for the activator and Knative Revisions to enforce that requests are routed through the Knative Ingress.
- Expected outcome: Users will be able to use NetworkPolicy to restrict access to their Knative Services at a network (L4 / TCP) level.
- Recommended Skills: Golang, Kubernetes networking, Envoy or protocol familiarity with HTTP
- Mentor(s): Evan Anderson @evankanderson
- Expected project size: 350h
- Difficulty: Hard
- Upstream Issue (URL): https://github.com/knative/serving/issues/6520

#### Improving Observability in Knative Eventing

- Description: We see users struggling to observe what happens inside Knative Eventing and we want that to be improved by providing easy to use tools. The idea is divided into stages. First stage is to write code (python and/or golang) that implements a plugin for Knative command-line interface (kn CLI). The plugin takes output from observability data gathered by Knative and answers simple questions such as: where did my event go based on event id? Show clusters/groups of common traces and show exceptions? The plugin should be able to verify that necessary Knative configuration for observability is enabled, access server side components. Possible next stages may be to create active probes that add to CLI capability to send probe events to specific Knative components (such as Kafka source or broker) and report if they work as expected (health checks). Another area to explore is using conversational AI to improve the plugin by using AI to parse natural language input and/or process available observability data for common Knative questions. As part of the work there may be proposed fixes and improvements for identified gaps in Knative observability that may be discovered when testing the plugin.
- Expected outcome: Improved Knative Eventing observability, improved documentation and published one or more blog posts
- Recommended Skills: Python, data science skills, Golang, Kubernetes
- Mentor(s): Aleksander Slominski @aslom, Ansu Varghese @aavarghese, and Lionel Villard @lionelvillard
- Expected project size: 350h
- Difficulty: Medium
- Upstream Issue (URL): https://github.com/knative/eventing/issues/6247

0 comments on commit 3d97893

Please sign in to comment.