knative
/
community
mirror of https://github.com/knative/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add charters for all WGs that have them. (#547)

This commit is contained in:
Evan Anderson 2021-04-01 09:22:23 -07:00 committed by GitHub
parent 039674552a
commit 619dba57d9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
8 changed files with 548 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
working-groups/WORKING-GROUPS.md
View File

@ -76,6 +76,7 @@ API
| Artifact | Link |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | TODO (historical, was created before formal WG process) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1HqLJ8uNm5KmKPlMzQmbfDy0haybEUrPydsp7gNBrl20/edit) |
| Community Meeting Calendar | Wednesdays 10:30a-11:00a PST <br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -96,6 +97,7 @@ conventions
| Artifact | Link |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./client/CHARTER.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1cD7NkJJhSBpo2Q6RBHrbrSe6R5zjTZgO_YDGAluQ_oI/edit) |
| Community Meeting Calendar | Tuesdays, alternating between 10:30a-11:00a Pacific and 3:30p-4:00p Central European every two weeks<br>[Calendar Invitation](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -105,10 +107,10 @@ conventions
| Slack Channel | [#cli](https://slack.knative.dev) |
| Github Team WG leads | [@knative/client-wg-leads](https://github.com/orgs/knative/teams/client-leads/members) |
| &nbsp; | Leads | Company | Profile |
| ----------------------------------------------------------- | ------------ | ------- | --------------------------------------------- |
| &nbsp; | Leads | Company | Profile |
| ----------------------------------------------------------- | ------------ | ------- | -------------------------------------------- |
| <img width="30px" src="https://github.com/navidshaikh.png"> | Navid Shaikh | VMware | [navidshaikh](https://github.com/navidshaikh) |
| <img width="30px" src="https://github.com/rhuss.png"> | Roland Huß | Red Hat | [rhuss](https://github.com/rhuss) |
| <img width="30px" src="https://github.com/rhuss.png"> | Roland Huß | Red Hat | [rhuss](https://github.com/rhuss) |
## Documentation
@ -117,6 +119,7 @@ repo.
| Artifact | Link |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./docs/CHARTER.md) |
| Forum | [knative-docs@](https://groups.google.com/forum/#!forum/knative-docs) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/13-neXVH-1n1ELWgukSzySnWj-4X6UB2pGGws2z2NH3M/edit) |
| Community Meeting Calendar | Weekly on Tuesdays, 9:30-10:00am PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -136,7 +139,7 @@ Event sources, bindings, FaaS framework, and orchestration
| Artifact | Link |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Charter / Mission | [Enable asynchronous application development through event delivery from anywhere.](https://github.com/knative/eventing/blob/main/docs/mission.md) |
| Charter / Mission | [Enable asynchronous application development through event delivery from anywhere.](https://github.com/knative/eventing/blob/main/docs/mission.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1Xha-FeunojN49OJN7W0WBnPMcRtp1ycYpbkiir6XsE0/edit) |
| Community Meeting Calendar | Wednesdays 9:00a-9:30a PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -159,6 +162,7 @@ Event delivery data plane.
| Artifact | Link |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./delivery/CHARTER.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/10pvpEAb6DZ0mplmSeg8fEAmmJtqimt03GEHRieOcMig/edit) |
| Community Meeting Calendar | Tuesdays 8:30a-9:00a PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -166,11 +170,11 @@ Event delivery data plane.
| Document Folder | [Folder](https://drive.google.com/drive/folders/1YcyeckwBNPApxh8vHAlscYe_w7sIA5TA) |
| Repos | [`knative/eventing`](https://github.com/knative/eventing), [`knative/eventing-contrib`](https://github.com/knative/eventing-contrib), (shares `eventing-*`) |
| Slack Channel | [#eventing-delivery](https://slack.knative.dev/messages/eventing-delivery) |
| Github Team WG leads | [@knative/channel-wg-leads](https://github.com/orgs/knative/teams/channel-wg-leads/members) |
| Github Team WG leads | [@knative/channel-wg-leads](https://github.com/orgs/knative/teams/channel-wg-leads/members) |
| &nbsp; | Leads | Company | Profile |
| -------------------------------------------------------- | ------------------- | ------- | --------------------------------------- |
| <img width="30px" src="https://github.com/matzew.png"> | Matthias Wessendorf | Red Hat | [matzew](https://github.com/matzew) |
| &nbsp; | Leads | Company | Profile |
| -------------------------------------------------------- | ------------------- | ------- | ------------------------------------------------------------------ |
| <img width="30px" src="https://github.com/matzew.png"> | Matthias Wessendorf | Red Hat | [matzew](https://github.com/matzew) |
| <img width="30px" src="https://github.com/slinkydeveloper.png"> | Francesco Guardiani | Red Hat | [slinkydeveloper](https://github.com/slinkydeveloper) |
## Eventing Sources
@ -179,6 +183,7 @@ Event producers and frameworks.
| Artifact | Link |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./sources/CHARTER.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/19txVRqA6_eY6ClGqoLRa0gPB50Ok7PT6_B6zDP1KtKQ/edit) |
| Community Meeting Calendar | Tuesdays 8:30a-9:00a PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -202,6 +207,7 @@ interest include: load balancing, routing, DNS configuration and TLS support.
| Artifact | Link |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | TODO (historical, was created before formal WG process) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/18m2XUDe-5QMFFBpLhIC7ozFnq12niYAqebtS3nMorhk/edit) |
| Community Meeting Calendar | Thursdays at 9:00a-9:30a PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -223,6 +229,7 @@ Managing, assessing system health and maintaining Knative clusters
| Artifact | Link |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./operations/CHARTER.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1m9oFlelI292Fzwi_sRUTrf69I-CcCwEVXkGcMAjDYqM/edit) |
| Community Meeting Calendar | Tuesdays at 10:00am PST <br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -243,6 +250,7 @@ performance/scale/load testing infrastructure
| Artifact | Link |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | [Charter](./productivity/CHARTER.md) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/16go22yTCiaNBtdjghhrqSxnsWkMbxRs4i_gSIezGzUk/edit) |
| Community Meeting Calendar | Thursdays, 10am PST<br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
@ -263,10 +271,11 @@ Autoscaling behavior of Knative Serving
| Artifact | Link |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Charter | TODO (historical, was created before formal WG process) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1-hezRkkLhnCkkEm6S09SkQR-BpF5xpTyhethYL5Zm6w/edit#) |
| Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1-hezRkkLhnCkkEm6S09SkQR-BpF5xpTyhethYL5Zm6w/edit#) |
| Community Meeting Calendar | Wednesdays at 9:30am PST <br>[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
| Meeting Notes | [Notes](https://docs.google.com/document/d/1-hezRkkLhnCkkEm6S09SkQR-BpF5xpTyhethYL5Zm6w/edit#) |
| Meeting Notes | [Notes](https://docs.google.com/document/d/1-hezRkkLhnCkkEm6S09SkQR-BpF5xpTyhethYL5Zm6w/edit#) |
| Document Folder | [Folder](https://drive.google.com/drive/folders/1IDDkJ3FD47xFSHY3iA9U2Q8th3Cwdo0K) |
| Repo prefixes | |
| Slack Channel | [#autoscaling](https://slack.knative.dev/messages/autoscaling) |
@ -291,7 +300,7 @@ Security concerns across Knative components
| Document Folder | [Folder](https://drive.google.com/drive/u/0/folders/1yOy_yU5vvUTFuxeYvhlY7uzIL4c4SSzX) |
| Repo prefixes | |
| Slack Channel | [#security](https://slack.knative.dev/messages/security) |
| Github Team WG leads | [@knative/security-wg-leads](https://github.com/orgs/knative/teams/security-wg-leads/members) |
| Github Team WG leads | [@knative/security-wg-leads](https://github.com/orgs/knative/teams/security-wg-leads/members) |
| &nbsp; | Leads | Company | Profile |
| ------------------------------------------------------------- | --------------- | ------- | --------------------------------------------------- |

127
working-groups/client/CHARTER.md Normal file
View File

@ -0,0 +1,127 @@
# Knative Client Working Group Charter
## Mission
The Knative Client Working Group maintains a delightful baseline operator-neutral Knative client developer experience, including documentation about what normative clients do, and a reference implementation of a normative client.
## Goals
- Provide a portable reference command-line client for Knative with a normative workflow.
- Provide guidance about normative uses of the Knative APIs to client developers.
- Provide reference implementations of Knative developer workflows as a library to be incorporated into other clients.
## Scope
In a new repo in the knative org:
- Maintain documentation around how the API can be used to create a delightful user experience for core Developer journeys, and client conventions for Knative as a whole and each Knative building block.
- Create and maintain a golang library for implementing the normative client flows for the Developer persona, for general Knative-wide conventions as well as workflows specific to each building block and their interactions. This library should support workflows for both graphical and command-line client tooling, though the group will only maintain an implementation of a command-line client.
- Create and maintain a standalone command-line client, `kn`, using the aforementioned library, that implements a developer experience for Knative that is portable across operators.
In working group meetings:
- Provide a forum to discuss non-CLI user tooling as well (web, etc.), and how the client libraries can support those too.
### Non-scope:
- Implementation of other experimental interfaces for Knative.
## Preliminary 3-Month Roadmap
**Month 1 (December. December barely exists.)**
- Get repo structure set up
- Start library for Serving
- Pick tech stack for CLI (set of libs to use for terminal manipulation & display etc)
**Month 2**
- Start CLI, using library for Serving
- One major user journey complete for Serving, ex "deploy a new image to a Service"
- With Build: Settle on supported path for deploy-from-source-dir
- With Eventing: Discuss user support for discovery story
**Month 3**
- Have at least two major user journeys completed e2e for Serving
## Details
### Documentation details
New WG will own <code>[normative-examples.md](https://github.com/knative/serving/blob/master/docs/spec/normative_examples.md)</code> and <code>[client-conventions.md](https://github.com/knative/serving/blob/master/docs/client-conventions.md)</code> from Serving; similar docs can start here, concerning any of Serving, Eventing, Build.
### Library details
- A Go library implementing core Knative functionality for the Developer persona, including:
- General Knative-wide functionality
- Library for reading and dealing with ready conditions and terminal conditions.
- Watching or polling them for completeness
- Reporting on partial completeness
- Support for the core user journeys across Knative projects, including cross-project integrations. Examples:
- Serving
- Creating Services
- Deploying software to Services
- Deploying from source: integrated with Build
- Deploying an image
- Managing the configurations of services
- Resource limits
- Concurrency
- Environment
- (etc)
- Rolling out traffic to revisions
- Rolling back
- Fetching and watching all Knative Serving objects
- Build/Pipeline
- Fetching build templates
- Creating builds using build templates
- From a source repository version
- From a directory of source (possibly using a technique similar to [Matt's proof-of-concept](https://github.com/mattmoor/kontext#kontext))
- Creating builds not using build templates (NB: Probably not part of most mainline developer experiences, but included for completeness)
- Creating namespace-scoped build templates
- Eventing
- Creating bindings from events to endpoints in services
- Listing available event sources
- Describing source capabilities and configuration options
- Creating event source instances (diff between CRD defining the source and an actual instance of a source) in a generic way, these vary wildly
- CRUD on Channels
- A way to find unused channels
- Any future Knative building blocks
### CLI details
A basic command-line client (or plugin to kubectl, chosen based on overall developer experience), built on the Go library, that provides a command-line interface for all the tasks.
- We like short command names. `kn`?
- Authentication using kubeconfig
- Output formatting and filtering similar to kubectl (tabular, json, yaml formats, templating)
### Responsibility also includes
- Tests for all of the above.
- Code coverage for all the above
- Any extra github automation for the repo
### Possible future scope:
- Client libs in other languages. (interest in py from google, at least)
### Out of scope:
- Operator concerns (Focusing the interface on the role of developer will lead to a better developer experience, and operator concerns are irrelevant to most developers. Also, operator concerns are more likely to involve non-Knative APIs, like RBAC)
- Installing cluster-scoped build templates
- Installing Knative
- Making cluster-scoped configuration choices
- Any functionality that relies on non-Knative APIs (Knative clusters are built using a variety of features, due to the "pluggable backends" and "duck typing" work we've been doing, and so if an API hasn't been standardized into Knative we can't assume a Knative cluster has it)
- (Currently) exposing a service outside the cluster
- RBAC management
- Binding a service to a domain name
- Installing Knative
- Any functionality that relies on a particular implementation of Knative. (Client libs should work the same against any implementation of Knative)
- Vendor extensions (aside from codifying where in the API they can go)
- Any particular happenstance/subtleties that aren't codified, for example in exact ordering of conditions becoming True for a happy-path operation.
- Conformance tests for Knative. These can and should **use** the client libraries we're working on, but deserve their own home.
## Working Group
To be a peer of the other Knative working groups, run weekly (to start), cancelled when we don't have enough to talk about.

79
working-groups/delivery/CHARTER.md Normal file
View File

@ -0,0 +1,79 @@
# Knative Event Delivery Working Group Charter
Last Updated: Nov 15, 2019
Note: the original document was written to focus on Knative Channels, but the TOC recommended refocusing on consistent data-plane behavior and the group renamed. The charter still contains many references to Channels.
## Mission
The Knative Event Delivery Working Group will reduce the friction of finding, implementing, and using Knative compliant Channels. We will specify the interface for event delivery such that multiple implementations can be used by higher level pieces. As well as create conformance tests to verify a given implementation implements the interface correctly and make that information available for operators and developers.
Event Delivery is the fundamental data-plane building block for most of the Eventing working group's APIs, including: Broker, Parallel, and Sequence. The stability and reliability of event delivery is thus critical for the majority of Eventing API's surface area. Due to the importance of event delivery, this newly proposed Working Group will lead the Spec, API, documentation as well as conformance test in a focused way, helping implementers of eventing components and other APIs depending on event delivery, to guarantee a consistent and efficient data tranfer API.
We expect that other working groups will focus on how channels are used and in particular creating working group for Broker, Parallel, and Sequence (and similar higher level constructs) if needed.
## Goals
- As an [Event Consumer](https://github.com/knative/eventing/blob/master/docs/personas.md#event-consumer-developer), the choice of Channel implementation with identical defined characteristics (e.g. persistence or in-order delivery) has no affect on me.
- As an [Event Producer](https://github.com/knative/eventing/blob/master/docs/personas.md#event-producer), the choice of Channel implementation has no affect on me.
- As a [System Integrator](https://github.com/knative/eventing/blob/master/docs/personas.md#system-integrator), I can create a new Channel implementation and use the conformance tests to verify that it meets all the requirements of a Channel implementation.
- As an Operator, I can find conforming Channel implementations and control which are available within the cluster.
- As an Operator, I can choose Channels based on additional, well defined characteristics, such as persistence or in-order delivery.
- As an Operator, I can understand Channel usage and locate errors.
## Scope
In the existing Eventing repo inside the knative org:
- Continue to evolve the [Channel Spec](https://github.com/knative/eventing/blob/master/docs/spec/channel.md).
- Continue to increase the coverage of the [Channel conformance tests](https://github.com/knative/eventing/tree/master/test/conformance).
- Explore [Channel error handling](https://github.com/knative/eventing/tree/master/docs/delivery).
- Maintain libraries to make Channels more consistent, such as [EventReceiver](https://github.com/knative/eventing/blob/master/pkg/channel/event_receiver.go) and [EventDispatcher](https://github.com/knative/eventing/blob/master/pkg/channel/event_dispatcher.go).
- Maintain OWNERS files within both the eventing and eventing-contrib repo for folders owned by the Channels WG. So that it is easier to track who is on track PRs and who is on track to become an approver or lead.
- Document and evolve the event delivery contract between all Knative pieces dealing with events, and manifest this contract in a “Knative Event Delivery Spec”.
Documentation:
- Explore different styles of Channel implementations, giving nuanced recommendations on the trade-offs between different designs (e.g. Job based vs singleton dispatchers).
- Maintain a list of conforming [Channel implementations](https://knative.dev/docs/eventing/channels/channels-crds/).
In working group meetings:
- Provide a forum to discuss and align work items related to the working group, status updates.
## Preliminary 3-Month Roadmap
Month 1
- Start to define the Event Delivery Spec.
- Verify the Channel Spec and reflect content from Event Delivery Spec.
- InMemoryChannel has error handling (dead letter queue).
- Document the different styles of Channels that currently exist and their trade offs.
- Increase the amount of the specification covered by the conformance tests.
Month 2
- At least one Channel implementation other than InMemoryChannel has error handling.
- Increase the amount of the specification covered by the conformance tests.
- Add observability to the Channel specification.
Month 3
- At least one Channel uses native error handling (e.g. RabbitMQ's dead letter exchange).
- 100% coverage of all MUST and MUST NOT directives in the specification covered by the conformance tests.
- Framework for the conformance tests to test optional Channel attributes, such as guaranteed delivery and in-order delivery.
- At least two Channel implementations that pass all conformance tests.
- Document which Channel implementations are available, whether they pass conformance tests, and any optional properties they guarantee (e.g. persistence, in order delivery, etc.).
## Working Group
We will operate as a partner group to Eventing, giving a brief update in the weekly Eventing working group meeting. We will additionally meet on a weekly basis, cancelled when there is a lack of agenda.
## Proposed Leads
- [Harwayne](https://github.com/Harwayne)
- [matzew](https://github.com/matzew)
## History
The Eventing WG created a [Channel Task Force](https://docs.google.com/document/d/1uxlulaAf2m_yZUqCIeI-inul2gsqP69PElnZdO0FHUo/edit#) in May 2019, lead by [Harwayne](https://github.com/Harwayne) and [matzew](https://github.com/matzew). It has been meeting on a weekly basis and has made progress on many of the issues above. As the scope of the task force has increased, it no longer has a clear exit condition. Therefore it feels more appropriate for it to be a working group, rather than a task force.

28
working-groups/docs/CHARTER.md Normal file
View File

@ -0,0 +1,28 @@
# Knative Documentation Working Group Charter
Authors: Sam O’Dell, ([odells@google.com](mailto:odells@google.com)), Richie Escarez ([rescarez@google.com](mailto:rescarez@google.com)), Ivan Nikittin ([ifnikitt@google.com](mailto:ifnikitt@google.com))
## Mission
To write, edit, review, organize, and maintain contributions to the Knative open source documentation.
## Goals
Create a first-class documentation experience for Knative users by:
- Establishing a documentation strategy and aligning new contributions with it
- Defining style guidelines and terminology for the doc set
- Coordinating the efforts of documentation contributors and encouraging new contributions
- Adopting appropriate tooling to help with automation
- Creating processes that:
- Lower the time to address PRs and issues
- Protect the quality of the documentation, especially over time
- Contributing to overall product direction through our experience as the earliest Knative users
## Scope
This group will primarily concern itself with the content of the [Knative Docs repo](https://github.com/knative/docs), but may also contribute to the documentation in other [Knative](https://github.com/knative) repos.
## Documentation Working Group Roadmap
[Link to Roadmap](https://docs.google.com/document/d/1A0H2lpH8FQ0RQxkdXbLz-tbFsM4qtUByARPHkLuDOdw/edit#)

67
working-groups/operations/CHARTER.md Normal file
View File

@ -0,0 +1,67 @@
# Knative Operations Working Group Charter
Created: 2019-04-26 / Last Updated: 2019-05-06
## Charter
### Mission
The Knative Operation Working Group provides best practices for managing, assessing system health and maintaining Knative clusters. The initial focus will be on how Knative is installed, removed, and upgraded.
### Goals
- Provide a means to install Knative [Serving/Build/Eventing] with operator(s) specified options
- Operator specified defaults such as timeouts and concurrency
- Network preferences, Istio / Gloo / others
- Build Template selection
- Eventing component selection
- Provide a means to install Knative with limited/no internet access
- Provide a means to upgrade/downgrade Knative with limited/no user visible impact to their service
- Provide guidelines on determining the overall health of Knative
- Provide cluster sizing and lifecycle recommendations
- An entrypoint and forum for dogfooders to give feedback
### Non-Goals
- The knative operator does not manage or install Istio, or other dependents.
- But we might want to have the option to recommend other operators for this task. Like `knative.spec.istioOperator = yes` please.
### Scope
- Tooling for installation/removal/upgrades/downgrades
- Management mechanisms for:
- namespace setup (if needed)
- Quota and RBAC management
- Build and registry configuration
- integration with existing cluster o11y
- Debugging tools for operator personas.
- Define more specific "operator" sub-personas within the Knative "operator" persona (e.g. auditor, cloud provider, IT provider, etc)
- Collect feedback from operators on the usability of Knative
- Collaborate w/ Documentation Working Group on documentation for installation/removal/upgrades/downgrades
- Collaborate w/ Observability Working Group on metrics for health of Knative
- Collaborate w/ Productivity Working Group on using best-practice installation for testing
## Lead Nomination
Ben Browning (bbrowning), Gregory Haynes (greghaynes), Kenny Leung (k4leung4)
## Roadmap\*
- Month 1 ~ Knative 0.7
- Implement all tasks under [Setting Up A Working Group](https://github.com/knative/community/blob/master/WORKING-GROUP-PROCESSES.md#setting-up-a-working-group)
- Set up separate repo for each of Knative serving/eventing
- Enable operator installs for current version of Knative Serving
- Month 2 ~ Knative 0.8
- Adopt operator installation usage for automated Knative Serving
- Decide on parameters for customization for Knative Serving
- Enable operator installs for Knative Build/Eventing
- Month 3 ~ Knative 0.9
- Investigate using operator for test execution
- Explore upgrade scenarios for Knative Serving using operator
- Assumes adoption of operators
## Previous Efforts
- [Knative Operator Working Group Proposal](https://drive.google.com/open?id=11cenPfZrEU04OFQYTE_6e_LrOw07HPOkeT1_Gigmy7U)

65
working-groups/productivity/CHARTER.md Normal file
View File

@ -0,0 +1,65 @@
# Contributor Productivity Working Group Charter
This is the proposal of creating contributor productivity working group for Knative.
# Mission
The mission of Contributor Productivity working group is to develop engineering guidelines, tools and infrastructure for Knative open source community to enable high quality and high velocity deliverables, to drive measurable and predictable releases, and to achieve high community collaboration and overall productivity.
# Goals
- Foster collaboration among contributors for common needs
- Identify top priorities or pain points
- Formulate guidelines and processes around testing, continuous integration, code velocity, and release packaging.
- Develop/Evangelize reusable tools and infrastructure to be utilized by contributors across repos for various purposes such as E2E testing, conformance testing, performance/scalability testing, project health reporting, product troubleshooting/diagnostics and etc. More specifically we’d graduate reusable tools to kubernetes/test-infra.
- Drive up contributor experience with ongoing improvements to automations around code life cycle such as issue creation, triage, code review, test and release. The goal is to reduce contributor overhead, minimize product defects and improve overall efficiency. In turn, it shall help developer and operator experience with better product quality and more efficient releases.
# Scope
- Project health
- Define metrics (such as listed below) to measure project health, and deliver automation for improving project health.
- Code coverage
- API coverage
- Release churns
- PR latency (time to merge)
- Onboarding velocity (time to PR)
- Issue Triage velocity
- Issue Resolving Velocity
- Have automation in place to help drive up project health metrics with opt-in (default off) vs. opt-out (default on) options; and each WG can decide whether they are in or out.
- Test framework
- Ensure there is common test infrastructure in place to run unit, build, E2E and conformance tests, to output logs and metrics from tests, and to visualize logs/metrics.
- CI/CD workflows
- Maintain presubmit and postsubmit workflows to gate the quality of code checkin and quality of release
- Ensure there is sufficient monitoring in place to monitor the health of workflow and infrastructure themselves
- Release criteria/process
- Define and implement release criteria and process
- [Performance/Scalability/Load testing](https://docs.google.com/document/d/1_LXxZc_dlmFexILC27TnitFSFxP3l9mUkmGf_uTRYHc/edit)
- Working with individual feature WG (serving, scaling, build, control plane, eventing) to identify common requirements and provide a shared framework for each WG to consume. Initial thinking of common need includes cluster creation/setup, load profiles, test orchestration, result collection, metric visualization and etc. The corresponding framework code will exist at test-infra repo.
- Individual feature WG will be responsible for designing and implementing the actual testing, the corresponding test code will exist at individual repo.
- Collaborate with partner teams to reuse existing performance/load testing infrastructure as well as environment whenever possible
- Link above has more detailed proposals
- Troubleshooting experience
- Ensure sufficient automation and documentation is in place for self-service Knative troubleshooting
- Will use Knative/test-infra repo for code, maybe a good idea to rename it for broader purpose as outlined in this doc
# Initial set of leads:
- Adriano Cunha (adrcunha on github)
- Jessie Zhu (jessiezcc on github)
# Proposed 3 Month Roadmap
- M8:
- Set up regular WG meetings and establish forms of communication
- M9:
- Document existing development/release workflows to form a common understanding within the community
- Collect feedback on onboarding/development experience from the community from various sources such as meetings, slack, social media
- Define performance/load testing goals for different scenarios (contributor vs. developer)
- Finalize methodologies for perf/load testing
- M10:
- Build tools to measure community satisfaction around onboarding, developer, test, troubleshoot experience.
- Contributor friendly onboarding & troubleshooting experience based on feedbacks from M8
- At least one WG adopting perf/load test infra (scaling)
- Project health dashboard open to community
- M11
- Shareable performance/load test toolset
- Build tools to gather and track structured community feedback
- Drive up community satisfaction based on measurements from M9

82
working-groups/security/CHARTER.md Normal file
View File

@ -0,0 +1,82 @@
# Security Working Group Charter
## Intro
The “aaS” in FaaS stands for “as-a-service”. Many users would like to use Knative as the basis of a multi-tenant FaaS or PaaS-style platform. Even users who do not need hard multi-tenancy will wish to be confident of Knative’s security in single-tenant and soft multi-tenant scenarios. Currently the project provides limited guidance for how to configure and deploy itself successfully in these environments. The Security Working Group’s mission will be to fix this, by improving documentation, code, and process as needed to harden Knative for these use cases.
## Mission
The Security Working Group is responsible for helping users successfully run Knative in security sensitive environments. This mission will involve documentation, proactive exploratory testing, fixing of gaps, and production of necessary manifests and example security policies for various use cases.
The Working Group will evaluate new and existing features for their security impact, and where necessary will work with other Working Groups to add features and close gaps in order to support security-sensitive and multi-tenant use cases. The overarching goal is to, as well as to promote a security-conscious mindset throughout the project.
Example features and tasks which could fit within this mission (see also “Goals”, below):
- Documented recommendations and example manifests for setting up NetworkPolicy to prevent access between namespaces and for enabling mTLS.
- Documented recommendations and example manifests for securing traffic between Eventing and Serving workloads.
- Filling gaps in the security story for integrating eventing and serving. .
- Document how to expose Knative as a multi-tenant service. For example configuring a secure runtime (gVisor, Kata containers, firecracker etc), adding the AlwaysPullImages admission controller and appropriate security policies, setting up appropriate NetworkPolicy.
- Documenting and improving the current security posture of Knative for various specific use cases, such as multi-tenant environments, air-gapped environments, and security-sensitive single tenant environments.
- A suggested PodSecurityPolicy (or OPA policy etc) to be used with Knative.
- Tests and configuration to run Knative with gVisor, ClearContainers, and other isolation technologies.
- Integration with open source security tools, eg. Falco.
- Setting up and maintaining Security Scanners, Linters and other automated tools (and initially fixing any found problems).
- Defining processes for reporting, handling and pro-actively auditing the system for vulnerabilities; for example organising exploratory testing sessions.
- Defining and owning the process for handling reported security vulnerabilities (but see “non-goals” section w.r.t.not directly handling vulnerability reports, since this likely would mandate a restricted membership group).
## Working Group
Since this work cross-cuts Serving, Eventing, and Documentation, and since Security and Multi-tenancy are on-going considerations for the project, this will be a top-level working group which will work closely with other working groups.
## Goals
- Ensure that documentation and sample configs exist which permit Knative to be deployed securely (to the extent possible) in security-sensitive and multi-tenant environments. Close gaps (working with other WGs) and add features as needed to make this possible.
- Share and document best practices between those using Knative for security-sensitive use cases.
- Provide example configurations that lock down the upstream cluster to maximize security (i.e. to configure the system so that only the Knative APIs are available, and security-sensitive fields such as securityContext and serviceAccountTokens are blocked).
- Validate new feature proposals for their ability to be implemented in secure and multi-tenant environments.
- Consider the API surface of Knative to identify and fix potential DOS attacks and other security vulnerabilities, and to ensure Knative can be successfully used in multi-tenant environments, and for security-sensitive use cases.
- Publish design docs on Knative Threat Model, Security Analysis docs etc.
- Set up processes to ensure ongoing security of the platform. For example security linters, scanners, fuzzers, patch managers, and at a higher level through ensuring security is considered holistically and pro-actively by the project as a whole.
- Run a (ideally regular) brainstorming/exploratory session where we proactively brainstorm, investigate and mitigate potential attack vectors against the platform.
## Non-Goals
- Hard multi-tenancy in the unrestricted upstream platform. We will seek to upstream features as needed, but we assume achieving the goal for Knative in the short term may imply blocking access to some features in the underlying platform.
- Guaranteeing the security of the platform - this is ultimately up to vendors, administrators and operators; the WG mission is to provide guidance and share best practices to enable these people to be successful.
- Responsibility for specific vulnerabilities (though the WG may be a good place to define and steward a general process for handling vulnerabilities, security scanning etc, actively being responsible for managing specific reported vulnerabilities would likely require a closed WG).
## Scope
### In the existing repos:
- Provide cross-cutting input on security and multi-tenancy concerns.
- Provide documentation and example configurations for deploying Knative in multi-tenant environments, for example PodSecurityPolicies, NetworkPolicies, Secure Runtimes (some of this might end up being in a different repo).
- Fill gaps needed to use securely, as appropriate. For example rate limiting for DOS attack mitigation, network policy, podsecuritypolicy (or related new hotness as it’s deprecated :)).
- Set up & own automation and security scanning tools, linters.
- Set up & own test infrastructure for deploying and testing against an environment with limited RBAC rules.
### In working group meetings:
- Provide a forum to discuss and document security-sensitive use cases, experiences and requirements, and to surface gaps and needed features.
- Provide a forum to discuss potential new feature proposals WRT security and multi-tenant/security-sensitive-single-tenant use cases.
- Perform pro-active exploratory testing for vulnerabilities, DOS vectors etc.
- Discuss, prioritise and document the current and desired security posture of the project with regard to various scenarios (e.g. security-sensitive single tenant, air-gapped, multi-tenant etc).
## Preliminary 3-month Roadmap
- Document, with appropriate warnings about limitations, the current security recommendations for deploying Knative in various environments, for example hosted multi-tenant, private/trusted multi-tenant, secure single tenant.
- Provide and document an optional set of RBAC rules, PodSecurityPolicies etc which give access only to public Knative APIs, and block access to insecure features (securityContext, service tokens etc).
- Define and document a process for reporting and handling vulnerabilities (see discussion in [https://github.com/knative/community/pull/258](https://github.com/knative/community/pull/258))
- Set up infrastructure and CI automation to test changes against a restricted-RBAC, restricted PodSecurityPolicy environment. Close any found gaps.
- Define and add a security section to the Project Proposal Template to ensure we explicitly consider security implications of new features.
- Working with Networking WG, create NetworkPolicies to secure access between namespaces and between the knative-serving namespace and container namespaces.
## Potential Future (6-12 month) Items
- Work with Eventing and Serving WG to provide secure communication between Events and Services in as networking-provider agnostic a way as possible.
- Working with Documentation WG, provide deployment instructions for configuring Knative with a secure container runtime (e.g., gVisor, Kata Containers)...
## Proposed Leads
- Julian Friedman (IBM)
- Evan Anderson (VMware)

80
working-groups/sources/CHARTER.md Normal file
View File

@ -0,0 +1,80 @@
# Knative Sources Working Group Charter
Author(s): Scott Nichols
Last Updated: Oct 30, 2019
## Mission
The Knative Sources Working Group will reduce the friction of creating, finding, and implementing Knative compliant Sources. We will enable new ways to create, test, install, deploy and observe applications that produce or bridge events onto a cluster for consumption.
## Goals
- As a Developer Persona, enabling the creation of custom sources from new or existing code/containers with little to no changes.
- As a Developer Persona, allow for easy understanding of existing and potential sources installed in a cluster.
- As an Operator, installing new sources is trivial, and not a burden on the overall health of the cluster.
- As a Contributor, enable new methods for allowing new sources to be created allowing for user provided code and containers to adhere to the source specification defined by Knative Eventing.
## Scope
In the existing Eventing repo inside the knative org:
- Continue to evolve the [Source Spec](https://github.com/knative/eventing/blob/master/docs/spec/sources.md).
- Expand on the Pod-Specible Sources work [outlined](https://docs.google.com/document/d/159-xjBwougBWHOigWUk42tHSB_T1As6zdPwb_9zK38s/edit#heading=h.n8a530nnrb), and POC [implemented](https://github.com/n3wscott/sources).
- Explore the concept of sidecars that enable and extend existing pods to emit CloudEvents, implement overrides, and possibly dynamically update the sink target based on configuration.
- Leverage the POC from [Auto-Container-Source](https://github.com/Harwayne/auto-container-source) and expand it to include all implemented Pod-Specable sources.
- Provide examples of custom sources implemented in several languages (Go, Java, Javascript, Python).
- Provide SDK and test suite for event sources
- Provide test conformance suite to verify existing and knative sources are [Source Spec](https://github.com/knative/eventing/blob/master/docs/spec/sources.md) compatible (and versioned). Run automatic tests and publish results for official and nonofficial knative sources.
- Collaborate with CLI for good UX on creating and discovery of Sources installed and/or running.
In working group meetings:
- Provide a forum to discuss and align work items related to the working group, status updates.
Sources WG Overall responsibility:
- Maintaining Sources inside of knative/eventing.
- Advising compatibility with Source contracts contributed to Knative inside of knative/eventing-contrib.
- Ensuring that there are high-quality Sources for the most important (as decided by the WG) event-producing systems.
- Managing and directing the larger Source-authoring ecosystem.
- Tracking long-term efforts around improving the efficiency of Sources when working in coordination with other Knative Eventing components (e.g. upstream filter propagation, batching, or other optimizations).
## Preliminary 3-Month Roadmap
Month 1
- Establish principles of Sources (as both Developer and Operator Personas).
- Define Pod-Specable Run Time Contract (Ref: [work in progress](https://github.com/n3wscott/sources/blob/master/docs/runtime-contract.md)).
- Implement 3 Pod-Specable (TBD: DeploymentSource, JobSource, CronJobSource) sources in the sources.knative.dev API group inside of Eventing.
- Deprecate ContainerSource and CronJobSource in sources.eventing.knative.dev.
- Migrate to new api group: ‘sources.knative.dev’
- Engage with CLI to develop a long term UX plan for creation of sources.
Month 2
- Implement 3 more Pod-Specable Sources (TBD: DaemonSource, StatefulSetSource, ServiceSource)
- Enable Auto\*Source for 2-3 sources (TBD: DeploymentSource, ServiceSource).
- Implement Conformance Test for runtime contract of Pod-Specable Sources.
- Engage with Operator to see path forward for additional source installations.
- Began implementing example sources for 1-2 languages for 1-2 Source types.
- CLI is able to discover and create Sources.
- Start Sidecar and usability research for Advanced Lazy Sources..
- Create
Month 3
- CLI can create and discover Sources from labeled CRDs.
- Implement remaining Pod-Specable resources (TBD: ReplicaSet, Pod)
- Enable Auto\*Source for remaining Sources.
- Implement Examples for remaining languages as needed.
- Operator integration has been determined and work is ongoing.
- TBD: Additional Sidecar work per results of Advanced Lazy Sources research.
## Working Group
We will operate as a partner group to Eventing, giving a brief update in the weekly Eventing working group meeting. We may additionally meet on a weekly basis, cancelled when there is a lack of agenda.
### Nominated Leads:
Nacho Cano, Scott Nichols, Ville Aikas, Lionel Villard