Add Knative GSoC ideas #779
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 | ||
|
There was a problem hiding this comment. We need to add a maintainer to this third project in addition to these mentors -- forgive me if one of these three are already, we may need to update the lists. There was a problem hiding this comment. We also need mentor email addresses to add folks to the system when the time comes. Could you add them @aliok? There was a problem hiding this comment.
@nate-double-u They are all maintainers. Is there a system or something like that at CNCF side where they are not listed? Where are those lists, if it is a public list? There was a problem hiding this comment.
@nate-double-u sorry about that. I was checking the GSOC 22 doc and didn't see any email addresses in that doc. Would you like to see the email addresses in the doc? ...which might be bad because of spam... or in the list you mentioned previously? I can provide them to you in Slack DM. There was a problem hiding this comment.
This is the list I use to check who is a maintainer: https://github.com/cncf/foundation/blob/main/project-maintainers.csv This list sometimes drifts out of sync with who is actually a maintainer, so if this isn't correct anymore, please update it 🙂 There was a problem hiding this comment.
I'd prefer all the data in one place, but I'm sympathetic to privacy concerns. If there are public email addresses please share them here, otherwise please send them via DM. There was a problem hiding this comment. One thing which may be tripping up the system is that Knative emulated both Kubernetes and Istio's governance model with a TOC/Steering Committee and smaller sub-area leads (called working group leads in Knative). We also have individuals who are approvers for code but aren't in a leadership role. The working group leads are similar to SIG leads in Kubernetes, but I'm not sure if they or approvers for specific areas of the project are in that maintainers file. There was a problem hiding this comment. I am a bit confused about this CSV file and found other people got similar confusions :) I found this ticket and added a comment there: cncf/foundation#433 (comment) @nate-double-u The issue is, mentors listed in that idea are not in Knative's steering committee or in technical oversight committee. Hence, they're not in that CSV file. However, they're the "approvers" for the component for the project idea. Similar situation applies to me, with the first idea ("Multiple Knative Eventing control planes"). As I wrote in my comment (cncf/foundation#433 (comment)), it might be good to specify who can be listed as the mentors. Or, if mentoring WG needs sponsorship/approval from the people in that CSV file. There was a problem hiding this comment. Having said these about improving the process here, switching back to practical side... Mentors listed in the first and the third idea are the approvers (SMEs) for the relevant components and they can provide mentorship in GSoC. |
||
| - Expected project size: 350h | ||
| - Difficulty: Medium | ||
| - Upstream Issue (URL): https://github.com/knative/eventing/issues/6247 | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added this TOC as well. Let me know if you would like me to remove it.
TOC was there in 2022 doc: https://github.com/cncf/mentoring/blob/main/summerofcode/2022.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the TOC. Usually i add it when we move projects from ideas to accepted. If folks update it as they add ideas i'm happy to leave it in, but if folks don't then I'd rather take it out and add it all at once with a tool at the end.