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

Merge branch 'main' into amye-adoc-to-md

This commit is contained in:
Amye Scavarda Perrin 2022-03-30 17:50:29 -07:00
parent 4614f3eb2f da2e98ff11
commit ed0b81118e
18 changed files with 1695 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTORS.md
View File

@ -6,6 +6,7 @@ List below is the official list of TOC contributors, in alphabetical order:
* Alex Chircop, StorageOS (alex.chircop@storageos.com)
* Allen Sun, Alibaba (allensun.shl@alibaba-inc.com)
* Amit Raj, InMobi (amitbmas90@gmail.com)
* Andrés Vega, Hewlett-Packard Enterprise (andres.vega@hpe.com)
* Andy Santosa, Ebay (asantosa@ebay.com)
* Ara Pulido, Datadog (ara.pulido@datadoghq.com)
@ -40,6 +41,7 @@ List below is the official list of TOC contributors, in alphabetical order:
* Gou Rao, Portworx (gou@portworx.com)
* Ian Crosby, Container Solutions (ian.crosby@container-solutions.com)
* Jeyappragash JJ, Independent (pragashjj@gmail.com)
* Jie Ding, Linkall (jie.ding@linkall.cloud)
* Jinming Yue, Caicloud (yuejinming@caicloud.io)
* Joe Beda, Heptio (joe@heptio.com)
* John Hillegass, Capital One (john.hillegass@capitalone.com)

1
EMERITUS.md
View File

@ -21,5 +21,6 @@ We would like to acknowledge previous TOC members and their huge contributions t
* Liz Rice (3/11/2019-2/4/2022)
* Saad Ali (2/4/2020-2/4/2022)
* Sheng Liang (2/4/2020-2/4/2022)
* Alena Prokharchyk (3/18/2020-3/18/2022)
We thank these members for their service to the CNCF community.

8
README.md
View File

@ -9,17 +9,17 @@ The CNCF TOC is the technical governing body of the CNCF Foundation. It admits a
## Members
* **Alena Prokharchyk** (term: 2 years - start date: 3/18/2020 - 3/18/2022) [TOC-appointed]
* **Erin Boyd** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [GB-appointed]
* **Dave Zolotusky** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [EndUser-appointed]
* **Cornelia Davis** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [GB-appointed]
* **Lei Zhang** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [GB-appointed]
* **Davanum Srinivas** (term: 2 years - start date: 3/18/2021 - 3/18/2023) [TOC-appointed][TOC Chair]
* **Justin Cormack** (term: 2 years - start date 2/4/2022 - 2/4/2024) [Maintainer-appointed]
* **Ricardo Rocha** (term: 2/4/2022 - 2/4/2024) [EndUser-appointed]
* **Emily Fox** (term: 2 years - start date: 2/4/2022 - 2/4/2024) [GB-appointed]
* **Cornelia Davis** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [GB-appointed]
* **Davanum Srinivas** (term: 2 years - start date: 3/18/2021 - 3/18/2023) [TOC-appointed]
* **Matt Farina** (term: 2 years - start date 2/4/2022 - 2/4/2024) [GB-appointed]
* **Richard Hartmann** (term: 2 years - start date 2/4/2022 - 2/4/2024) [GB-appointed]
* **Lei Zhang** (term: 2 years - start date: 2/1/2021 - 2/1/2023) [GB-appointed]
* **Katie Gamanji** (term: 2 years - start date: 3/18/2022 - 3/18/2024) [TOC-appointed]
Election [schedule](process/election-schedule.md)

7
docs/projects.md
View File

@ -110,8 +110,8 @@
[karmada](https://github.com/karmada-io/karmada)|TOC Vote|[6/9/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[9/14/2021](https://github.com/karmada-io/karmada) | Sandbox
[Inclavare Containers](https://github.com/alibaba/inclavare-containers)|TOC Vote|[6/17/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[9/14/2021](https://github.com/alibaba/inclavare-containers) | Sandbox
[SuperEdge](https://github.com/superedge/superedge)|TOC Vote|[6/20/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[9/14/2021](https://github.com/superedge/superedge) | Sandbox
[Cilium](https://github.com/cilium/cilium)|TOC Vote|[10/13/2021](https://lists.cncf.io/g/cncf-toc/message/6164)|[10/13/2021](https://lists.cncf.io/g/cncf-toc/message/6288) | Incubating
[Dapr](https://github.com/dapr/dapr)|TOC Vote|[10/14/2021](https://lists.cncf.io/g/cncf-toc/message/6293)|[11/03/2021](https://lists.cncf.io/g/cncf-toc/message/6338) | Incubating
[Cilium](https://github.com/cilium/cilium)|Justin Cormack|[10/13/2021](https://lists.cncf.io/g/cncf-toc/message/6164)|[10/13/2021](https://lists.cncf.io/g/cncf-toc/message/6288) | Incubating
[Dapr](https://github.com/dapr/dapr)|Lei Zhang|[10/14/2021](https://lists.cncf.io/g/cncf-toc/message/6293)|[11/03/2021](https://lists.cncf.io/g/cncf-toc/message/6338) | Incubating
[OpenELB](https://github.com/kubesphere/openelb)|TOC Vote|[7/7/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[11/09/2021](https://github.com/kubesphere/openelb) | Sandbox
[Open Cluster Management](https://github.com/open-cluster-management-io)|TOC Vote|[7/11/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[11/09/2021](https://github.com/open-cluster-management-io) | Sandbox
[VS Code Kubernetes Tools](https://github.com/Azure/vscode-kubernetes-tools)|TOC Vote|[10/25/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[11/09/2021](https://github.com/Azure/vscode-kubernetes-tools)| Sandbox
@ -121,6 +121,8 @@
[kube-rs](https://github.com/kube-rs/kube-rs)|TOC Vote|[10/30/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[11/16/2021](https://github.com/kube-rs/kube-rs)|Sandbox
[Devfile](https://github.com/devfile/api)|TOC Vote|[12/28/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[01/11/2022](https://github.com/devfile/api)|Sandbox
[Knative](https://github.com/knative)|Davanum Srinivas|[11/30/2021](https://lists.cncf.io/g/cncf-toc/message/6625)|[3/2/2022](https://lists.cncf.io/g/cncf-toc/message/6734)| Incubating
[Confidential Containers](https://github.com/devfile/api)|TOC Vote|[12/19/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[03/08/2022](https://github.com/confidential-containers)|Sandbox
[FabEdge](https://github.com/devfile/api)|TOC Vote|[12/28/2021](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842)|[03/08/2022](https://github.com/FabEdge/fabedge/)|Sandbox
## Graduated Projects
**Project**|**Sponsor**|**TOC Deck**|**Graduated**|**Maturity Level**
@ -199,6 +201,7 @@
[SPIRE/SPIFFE](https://github.com/spiffe/spire) | [08/17/2021](https://github.com/spiffe/spire/blob/main/doc/cure53-report.pdf) | [Announcement](https://www.cncf.io/blog/2021/08/17/open-sourcing-the-spiffe-spire-security-audit/) | CNCF | [Cure53](https://cure53.de)
[Flux](https://github.com/fluxcd/flux2) | [11/10/2021](https://fluxcd.io/FluxFinalReport-v1.1.pdf) | [Announcement](http://fluxcd.io/blog/2021-11-10-flux-security-audit/) | CNCF | [ADA Logics](https://adalogics.com)
[Argo](https://github.com/argoproj/argoproj) | [2/28/2022](https://github.com/argoproj/argoproj/blob/dd7cae43d81c5a11f21ff4ea0a4afadcae4799c7/docs/audit_fuzzer_adalogics_2022.pdf) | [Announcement](https://blog.argoproj.io/argo-security-automation-with-oss-fuzz-da38c1f86452) | CNCF | [ADA Logics](https://adalogics.com)
[etcd](https://github.com/etcd-io/etcd) | [3/11/2022](https://github.com/etcd-io/etcd/blob/main/security/FUZZING_AUDIT_2022.PDF) | [Announcement](https://etcd.io/blog/2022/etcd-integrates-continuous-fuzzing/) | CNCF | [ADA Logics](https://adalogics.com)
## Archived Projects

89
process/due-diligence-guidelines.md
View File

@ -20,7 +20,7 @@ To enable the voting TOC members to cast an informed vote about a
project, it is crucial that each member is able to form their own
opinion as to whether and to what extent the project meets the agreed
upon [criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc) for
sandbox, incubation or graduation. As the leader of a DD, your job
sandbox, incubation, or graduation. As the leader of a DD, your job
is to make sure that they have whatever information they need,
succinctly and readily available, to form that opinion.
@ -28,34 +28,34 @@ As a secondary goal, it is in the interests of the broader CNCF
ecosystem that there exists some reasonable degree of consensus across
the community regarding the inclusion or otherwise of projects at the
various maturity levels. Making sure that the relevant information is
available, and any disagreement or misunderstanding as to it's
available, and any disagreement or misunderstanding as to its
validity are ideally resolved, helps to foster this consensus.
### Where to start
* make sure you're clear on the [TOC Principles](https://github.com/cncf/toc/blob/main/PRINCIPLES.md),
* Make sure you are clear on the [TOC Principles](https://github.com/cncf/toc/blob/main/PRINCIPLES.md),
the [project proposal process](https://github.com/cncf/toc/blob/main/process/project_proposals.adoc),
the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc)
and [desired cloud native properties](https://www.cncf.io/about/charter/) are. The project sponsor (a member
of the TOC) should have assisted in crafting the proposal to explain why it's a good fit for the CNCF. If anything's
unclear to you, reach out to the project sponsor or, failing that, the TOC mailing list for advice.
* make sure you've read, in detail, the relevant [project proposal](https://github.com/cncf/toc/tree/main/proposals),
the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc),
and the [desired cloud native properties](https://www.cncf.io/about/charter/). The project sponsor (a member
of the TOC) should have assisted in crafting the proposal to explain why it is a good fit for the CNCF. If anything is
unclear to you, reach out to the project sponsor or, failing that, the TOC mailing list for advice.
* Make sure you read, in detail, the relevant [project proposal](https://github.com/cncf/toc/tree/main/proposals).
This will usually be in the form of an [open pull request](https://github.com/cncf/toc/pulls).
Consider holding off on commenting on the PR until you've completed the next three steps.
* take a look at some [previous submissions](https://github.com/cncf/toc/pulls?utf8=%E2%9C%93&q=is%3Apr)
Consider holding off on commenting on the PR until you have completed the next three steps.
* Take a look at some [previous submissions](https://github.com/cncf/toc/pulls?utf8=%E2%9C%93&q=is%3Apr)
(both successful and unsuccessful) to help calibrate your expectations.
* Verify that all of the basic [project proposal requirements](https://github.com/cncf/toc/blob/main/process/project_proposals.adoc) have been provided.
* do as much reading up as you need to (and consult with experts in the specific field) in order to familiarize yourself with the technology
landscape in the immediate vicinity of the project (and don't only use the proposal and that project's documentation as a guide in this regard).
* at this point you should have a very clear technical idea of what exactly the project actually does and does not do, roughly how it compares with and differs from
similar projects in it's technology area, and/or a set of unanswered questions in those regards.
* go through the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc) and for each item,
decide for yourself whether or not you have enough info to make a strong, informed call on that item.
* Verify that all of the basic [project proposal requirements](https://github.com/cncf/toc/blob/main/process/project_proposals.adoc) have been provided.
* Do as much reading up as you need to (and consult with experts in the specific field) in order to familiarize yourself with the technology
landscape in the immediate vicinity of the project (and do not only use the proposal and that project's documentation as a guide in this regard).
* At this point, you should have a very clear technical idea of what exactly the project actually does and does not do, roughly how it compares with and differs from
similar projects in its technology area, and/or a set of unanswered questions in those regards.
* Go through the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc) and for each item,
decide for yourself whether or not you have enough information to make a strong, informed call on that item.
* If so, write it down, with motivation.
* If not, jot down what information you feel you're missing.
* If not, jot down what information you feel you are missing.
* Also take note of what unanswered questions the community might have posted in the PR review that you consider
to be critically important.
### Some example questions that will ideally need clear answers
Most of these should be covered in the project proposal document. The
@ -65,29 +65,29 @@ the detail where necessary.
#### Technical
* An architectural, design and feature overview should be available.
* An architectural, design, and feature overview should be available.
([example](https://github.com/docker/notary/blob/master/docs/service_architecture.md),
[example](https://github.com/docker/notary/blob/master/docs/command_reference.md))
* What are the primary target cloud-native use cases? Which of those:
* What are the primary target cloud native use cases? Which of those:
* Can be accomplished now.
* Can be accomplished with reasonable additional effort (and are ideally already on the project roadmap).
* Are in-scope but beyond the current roadmap.
* Can be accomplished with reasonable additional effort (and are ideally already on the project road map).
* Are in-scope but beyond the current road map.
* Are out of scope.
* What are the current performance, scalability and resource consumption bounds of the software? Have these been explicitly tested?
Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)?
* What are the current performance, scalability, and resource consumption bounds of the software? Have these been explicitly tested?
Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)?
* What exactly are the failure modes? Are they well understood? Have they been tested? Do they form part of continuous integration testing?
Are they appropriate given the intended usage (e.g. cluster-wide shared services need to fail gracefully etc)?
* What trade-offs have been made regarding performance, scalability, complexity, reliability, security etc? Are these trade-offs explicit or implicit?
Why? Are they appropriate given the intended usage? Are they user-tunable?
* What are the most important holes? No High-Availability? No flow control? Inadequate integration points?
* Code quality. Does it look good, bad or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form.
Why? Are they appropriate given the intended usage? Are they user-tunable?
* What are the most important holes? No high availability? No flow control? Inadequate integration points?
* Code quality. Does it look good, bad, or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form.
Are there explicit coding guidelines for the project?
* Dependencies. What external dependencies exist, do they seem justified? Note: all core dependencies should be listed in the document along with the details of relevant repos
* Dependencies. What external dependencies exist; do they seem justified? Note: all core dependencies should be listed in the document along with the details of relevant repositories.
* What is the release model? Versioning scheme? Evidence of stability or otherwise of past stable released versions?
* What is the CI/CD status? Do explicit code coverage metrics exist? If not, what is the subjective adequacy of automated testing?
Do different levels of tests exist (e.g. unit, integration, interface, end-to-end), or is there only partial coverage in this regard? Why?
* What licensing restrictions apply? Again, CNCF staff will handle the full legal due diligence.
* What are the recommended operational models? Specifically, how is it operated in a cloud-native environment, such as on Kubernetes?
* What are the recommended operational models? Specifically, how is it operated in a cloud native environment, such as on Kubernetes?
#### Project
@ -105,9 +105,9 @@ Some details that might inform the above include:
* Does it have a documented governance model of any kind?
* Does it have committers from multiple organizations?
* Does it have a code of conduct?
* Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of it's dependencies compatible with their usage and CNCF policies?
* Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of its dependencies compatible with their usage and CNCF policies?
CNCF staff will handle the full legal due diligence.
* What is the general quality of informal communication around the project (slack, github issues, PR reviews, technical blog posts, etc)?
* What is the general quality of informal communication around the project (Slack, GitHub issues, PR reviews, technical blog posts, etc)?
* How much time does the core team commit to the project?
* How big is the team? Who funds them? Why? How much? For how long?
* Who are the clear leaders? Are there any areas lacking clear leadership? Testing? Release? Documentation? These roles sometimes go unfilled.
@ -116,7 +116,7 @@ Some details that might inform the above include:
#### Users
* Who uses the project? Get a few in-depth references from 2-4 of them who actually know and understand it.
* What do real users consider to be it's strengths and weaknesses? Any concrete examples of these?
* What do real users consider to be its strengths and weaknesses? Any concrete examples of these?
* Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed?
#### Contributor experience
@ -124,30 +124,29 @@ Some details that might inform the above include:
* Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc.
* Is it easy to contribute to the project as an external contributor? If not, what are the main obstacles?
* Are there any especially difficult personalities to deal with? How is this done? Is it a problem?
* Getting interviews with 2-3 external contributors is advisable for DD process, both from the community and technical perspective. It can help to identify technical depth in areas like extensibility, API design and general code architecture.
* Getting interviews with 2-3 external contributors is advisable for DD process, both from the community and technical perspective. It can help to identify technical depth in areas like extensibility, API design, and general code architecture.
* For more in-depth review of the contributor experience, consulting with [tag-contributor-strategy](https://github.com/cncf/tag-contributor-strategy) is always a good idea.
#### Context
* What is the origin and history of the project?
* Where does it fit in the market and technical ecosystem?
* Is it growing or shrinking in that space? Is that space growing or shrinking?
* How necessary is it? What do people who don't use this project do? Why exactly is that not adequate, and in what situations?
* How necessary is it? What do people who do not use this project do? Why exactly is that not adequate, and in what situations?
* Clearly compare and contrast with peers in this space. A summary matrix often helps.
Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others.
Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner.
Be suspicious if there appears to be one.
Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others.
Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner.
Be suspicious if there appears to be one.
#### Other advice
* Bring in other people (e.g. from your company) who might be more familiar with a
particular area than you are, to assist where needed. Even if you know the area,
particular area than you are, to assist where needed. Even if you know the area,
additional perspectives from experts are usually valuable.
* Conduct as much of the investigation in public as is practical. For example, favor explicit comments on the
submission PR over private emails, phone calls etc. By all means conduct whatever communication might be
* Conduct as much of the investigation in public as is practical. For example, favor explicit comments on the
submission PR over private emails, phone calls etc. By all means, conduct whatever communication might be
necessary to do a thorough job, but always try to summarize these discussions in the PR so that others can follow along.
* Explicitly disclose any vested interest or potential conflict of interest that you, the project sponsor,
the project champion, or any of the reviewers have in the project. If this creates any significant concerns regarding
impartiality, its usually best for those parties to recuse themselves from the submission and it's evaluation.
* Fact-check where necessary. If an answer you get to a question doesn't smell right, check the underlying data, or get a second/third... opinion.
the project champion, or any of the reviewers have in the project. If this creates any significant concerns regarding
impartiality, it is usually best for those parties to excuse themselves from the submission and its evaluation.
* Fact check where necessary. If an answer you get to a question does not smell right, check the underlying data, or get a second/third opinion.

3
process/project_proposals.md
View File

@ -76,11 +76,12 @@ All exceptions (and "no" outcomes) are handled by the TOC.
* The file containing the proposal should be located in [https://github.com/cncf/toc/tree/main/proposals/graduation](the graduation proposals directory).
* The proposal addresses how the project has grown since incubation and any concerns from incubation DD in addition to the standard graduation requirements.
* Projects will be reviewed on a rolling basis as they apply, instead of two meetings a year.
. * If a TOC member steps forward to support the project as a sponsor and the DD document is finalized, the TOC member kicks off two week period of time for public comment on the TOC mailing list
. * If a TOC member steps forward to support the project as a sponsor and determines the Graduation DD document is finalized, the TOC member kicks off two week period of time for public comment on the TOC mailing list
* The email should contain a link to the proposal pull request and incubation DD document.
* All TAGs, end users, TOC members, and community members are welcome to comment at this time on the mailing list.
* Historically, projects have done a TOC presentation as part of the graduation process. The TOC has gotten rid of the presentation requirement.
* If the TOC does not sponsor the project to move forward at that time, they will provide feedback to the project and the PR will be closed.
* If the Graduation DD document is not finalized, the TOC sponsor will begin the process to refresh the existing DD document and begin the public comment process.
. *TOC vote*
* TOC members assess whether project meets the [https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage](Graduation criteria)

219
proposals/incubation/backstage.md Normal file
View File

@ -0,0 +1,219 @@
# Propose Backstage to Incubation Stage
## Table of Contents
- [Introduction](#introduction)
- [Background](#background)
- [Recap: What is Backstage](#recap-what-is-backstage)
- [Progress Since Sandbox](#progress-since-sandbox)
- [Community](#community)
- [Technical](#technical)
- [Incubation Stage Requirements](#incubation-stage-requirements)
- [Adhere to CNCF IP Policy](#adhere-to-cncf-ip-policy)
- [Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope](#document-that-it-is-being-used-successfully-in-production-by-at-least-three-independent-end-users-which-in-the-toc’s-judgement-are-of-adequate-quality-and-scope)
- [Clear versioning scheme & release methodology](#clear-versioning-scheme-&-release-methodology)
- [Demonstrate a substantial ongoing flow of commits and merged contributions.](#demonstrate-a-substantial-ongoing-flow-of-commits-and-merged-contributions)
- [Security](#security)
- [Statement on Alignment with the CNCF Mission](#statement-on-alignment-with-the-cncf-mission)
- [Alignment with Other CNCF Projects](#alignment-with-other-cncf-projects)
- [Future Plans](#future-plans)
## Introduction
* Name: Backstage
* Website: [backstage.io](https://backstage.io/)
* Source Control: [Backstage on Github](https://github.com/backstage/backstage)
* Code of Conduct: [Backstage Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)
* License: [Apache 2](https://github.com/backstage/backstage/blob/master/LICENSE)
## Background
Backstage joined CNCF as a sandbox project in September 2020.
* [Link to Backstage Sandbox Proposal](https://github.com/cncf/toc/pull/476)
* [Link to Backstage presentation to App delivery SIG](https://docs.google.com/presentation/d/1raY4eVh4zbkt1KAlSWXGkEfSwo2XN7UaDli1GWbh5p8/edit#slide=id.g7f5557e96c_0_18)
* [App delivery SIG meeting notes](https://docs.google.com/document/d/1OykvqvhSG4AxEdmDMXilrupsX2n1qCSJUWwTc3I7AOs/edit#heading=h.dhgrk589hocy)
* [Link to Github organisation](https://github.com/backstage/backstage)
### Recap: What is Backstage
[Backstage​​](https://backstage.io/) is an open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables product teams to ship high-quality code quickly — without compromising autonomy.
Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end and is based upon three core feature sets:
* **[Create](https://backstage.io/blog/2020/08/05/announcing-backstage-software-templates)** - Backstage uses software templates to simplify setup, standardize tooling, and deploy with the click of a button. Using automated templates, engineers can spin up a new microservice, website, or other software component with your organization’s best practices built-in, right from the start.
* **[Manage](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)** - The software catalog is a centralized system that keeps track of ownership and metadata for all the software in your ecosystem (services, websites, libraries, data pipelines, etc). The catalog is built around the concept of metadata yaml files stored together with the code, which are then harvested and visualized in Backstage.
* **[Explore](https://backstage.io/blog/2020/09/08/announcing-tech-docs)**- How to find stuff? Backstage surfaces all the relevant information to users in relation to their components and services. From service metadata through the catalog, tooling to explore and manage through plugins, and documentation available right alongside the code. A single pane of glass to reduce context switching that can be built on with search or other discoverability tools, improving overall productivity and for engineers and users.
## Progress Since Sandbox
### Community
**Outreach:** As a project we hold regular community meetings each month, highlighting what is happening in the community with presentations from multiple adopters and discussions on current topics and interests in the community. Community sessions have on average **80 attendees**, are uploaded to a [community playlist hosted on Youtube](https://www.youtube.com/watch?v=3dV3aZo6JN8&list=PLf1KFlSkDLIBmA5TLXn2BzEHmwWzckP8y) and gained **4792 views**.
* [Backstage Community Hub on Github](https://github.com/backstage/community)
* [Backstage Community on Discord](https://discord.gg/gNPPdTHc)
The community statistics are extracted from [CNCF devstats](https://backstage.devstats.cncf.io/).
<table>
<tr>
<td><strong>Type</strong>
</td>
<td><strong>Start of Sandbox</strong>
</td>
<td><strong>In 2021</strong>
</td>
<td><strong>Current Total</strong>
</td>
</tr>
<tr>
<td>Adopters
</td>
<td>32
</td>
<td>28
</td>
<td>45
</td>
</tr>
<tr>
<td>Commits
</td>
<td>13,250
</td>
<td>8,540
</td>
<td>18,000
</td>
</tr>
<tr>
<td>Pull Requests
</td>
<td>3084
</td>
<td>1936
</td>
<td>4855
</td>
</tr>
<tr>
<td>Contributions
</td>
<td>34,107
</td>
<td>21,357
</td>
<td>284,000
</td>
</tr>
<tr>
<td>Forks
</td>
<td>903
</td>
<td>640
</td>
<td>1438
</td>
</tr>
</table>
### Technical
Since joining the sandbox, Backstage has technically evolved in multiple ways, some of the more substantial developments include;
* The plugin system has evolved in several ways
* More flexibility in how plugins are added into the application
* Cross version compatibility has been introduced to simplify maintenance
* It is now easier to mix and match different open source and internal plugins
* Improved Catalog scalability
* Horizontal scalability of the Catalog Backend with processing split into smaller chunks rather than one big loop.
* Load tested and instrumented the catalog with a large number of entities.
* Added processing cache to reduce computation in large environments.
* The introduction of Scaffolder Actions
* Ability to create and compose custom actions - with a myriad of custom actions being built by adopters and the community. [#5153](https://github.com/backstage/backstage/pull/5153), [#5849](https://github.com/backstage/backstage/pull/5849), [#6340](https://github.com/backstage/backstage/pull/6340)
* Horizontal scalability of the scaffolder backend
* [https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta](https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta)
* Introduced Backstage search alpha. With its composable frontend and extensible backend, engineers can design and build the search tool that suits their organization’s needs.
* Integrates with sources from both within and outside the Backstage ecosystem
* Pluggable search backends with implementations including Elasticsearch, Lunr and PostgreSQL.
* [https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform](https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform)
## Incubation Stage Requirements
#### **_Adhere to CNCF [IP Policy](https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy)_**
As an existing Sandbox project this is already in place
#### **_Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope_**
A list of ~40 public adopters can be found [here](https://github.com/backstage/backstage/blob/master/ADOPTERS.md). We’ve worked directly with ~75 companies in various stages of adopting, many of whom are non-public in their adoption.
The following are three highlighted examples of adopters:
* [American Airlines](https://www.aa.com/) - A major American airline and the world's largest airline when measured by fleet size. In their [own words](https://tech.aa.com/2021-02-03-american-loves-open-source/); _Backstage, or “Runway” as we call it internally, has quickly become a central hub for creating new projects and has helped us radically streamline project creation._
* [Netflix](https://www.netflix.com/) - An over-the-top content platform and production company. Netflix looked at a lot of different options to fill their developer portal needs. They chose Backstage because it’s built for extensibility and is an open source solution supported by a strong community. [Watch the panel discussion](https://youtu.be/ajN9-dWSVYs?t=1012s).
* [Zalando](https://www.zalando.de/) - Online fashion platform Zalando decided to move away from their existing developer console and migrated to Backstage instead for its extensibility. With help from the open source community, Zalando’s small internal team went from proof-of-concept to building a platform serving thousands of developers. [Watch their presentation from our community event](https://youtu.be/6sg5uMCLxTA?t=175).
* [Telus](https://www.telus.com/en/) - Canada’s largest telecom. Realizing that trying to find the owner of services by yelling in Slack channels was no longer tenable, TELUS turned to Backstage for its focus on developer experience. [Watch their presentation from our community event](https://youtu.be/UZTVjv-AvZA?t=188).
#### **_Clear versioning scheme & release methodology_**
* Backstage packages follow [semantic versioning](https://semver.org/)
* We maintain a changelog for each of the Backstage packages within the repo, as example our [CLI changelog](https://github.com/backstage/backstage/blob/9d0c74b00d22e9467674ae9a5fed4c80501e59cd/packages/cli/CHANGELOG.md)
* As an indication of health and maturity we also maintain a stability index for the Backstage API
We also follow a regular release cycle of Thursday each week and have fully [documented this flow](https://backstage.io/docs/plugins/publishing#creating-a-new-release) to set proper expectations across the community for our releases.
#### **_Demonstrate a substantial ongoing flow of commits and merged contributions._**
* [Commit Activity](https://backstage.devstats.cncf.io/d/74/contributions-chart?orgId=1&from=now-2y&to=now&var-period=w&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-company_name=All&var-company=all)
* In August 2021 there were a total of 676 contributions from 92 contributors. Up from a total of 35 contributors the year before.
* There are a total of 489 total contributors to the project as of September 2021
* [New Contributors over past year](https://backstage.devstats.cncf.io/d/52/new-contributors-table?orgId=1&from=now-1y&to=now)
* On average we have 6 new contributors joining each week
* There are on average 49 new PRs from non-maintainers on the project per week
* In the last 30 days the average time to close PRs was 8 hours 11 minutes
Full details can be found at [CNCF devstats](https://backstage.devstats.cncf.io/) dashboards for Backstage.
#### **_Security_**
Security processes are clearly documented [here](https://github.com/backstage/backstage/blob/master/SECURITY.md).
## Statement on Alignment with the CNCF Mission
Backstage restores order to an organization's infrastructure and enables product teams to ship high-quality code quickly without compromising autonomy. Its goal is to enable teams and organisations to take control of the growing number of services and complexity they maintain. As highlighted in the [CNCF charter](https://www.cncf.io/about/charter/), Backstage aims to empower organisations to build and run modern scalable applications with ease, bringing together technologies and products that makes sense for them through a single pane of glass.
In alignment with the [CNCF values](https://github.com/cncf/foundation/blob/master/charter.md#3-values), Backstage hosts a growing community of open plugins unlocking new functionality for the community and enables Backstage to run cloud agnostic to suit users needs. As a project we believe in an open Backstage that encourages the growth of our community helping to guide and develop Backstage both technically and in product direction.
### Alignment with Other CNCF Projects
**_Does the project align and actively collaborate with other CNCF projects._**
The main mechanism for extending Backstage and configuring initial deployments for organizations is through our [plugin model](https://backstage.io/docs/plugins/#docsNav). Contributors, end-users, 3rd party vendors and organisations can extend Backstage functionality and surface information or tooling to support Backstage users. There is a growing [plugin marketplace](https://backstage.io/plugins) with currently 45 plugins for platform owners to integrate. Including some plugins for existing CNCF projects;
* [K8s plugin](https://backstage.io/docs/features/kubernetes/overview)
* [Argo](https://roadie.io/backstage/plugins/argo-cd/?utm_source=backstage.io&utm_medium=marketplace&utm_campaign=argo-cd)
* [Harbor](https://github.com/BESTSELLER/backstage-plugin-harbor/blob/master/README.md)
* [GitOps](https://github.com/backstage/backstage/tree/master/plugins/gitops-profiles)
* [GKE](https://github.com/BESTSELLER/backstage-plugin-gkeusage/blob/master/README.md) (alongside k8s)
We also make use of [Helm Charts](https://backstage.io/docs/deployment/#docsNav) as another CNCF integration to deploy Backstage.
## Future Plans
The direction of travel for Backstage is highly influenced by the community contributions and the core maintainers will continue to support the requests, as it has been until today. Saying that, the clear commitment is to continue to be “community driven”, scaling the community support accordingly with the increasing number of [adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md), requests of support (in forums, chats, github issues, etc.) and contributions.
In addition to that, the core maintainers want to define a coherent roadmap for the whole product, focusing the improvements on strategic theming that we can summarize as follows.
* **Maturity,** to land to a stable version of the platform and a shared release plan, supporting the adopters with a clear lifecycle and cadence of releases.
* **Enablement** of new use cases and features, to extend the audience of the users who can benefit from the platform and empower them in doing better and faster (abstraction of the jobs to be done).
* **Foster innovation**, through the experimentation of the new features that the community can try and evaluate for future values and enhancements.
As a tangible plan for the platform enhancements developed by the core maintainers, but not only by them, you can check the [backstage.io roadmap page](https://backstage.io/docs/overview/roadmap) announcing the upcoming features for the ongoing quarter.
To get closer to the community, trying to take advantage of the momentum, we want to organize an in-person event entirely dedicated to Backstage, once the conditions allow it. The opportunity of a Backstage Developer Conference is loudly highlighted by the community and it would bring the involvement to the next level, where core-maintainers and contributors/enthusiasts will discuss together about the evolution of the platform.
The future ambitions for Backstage include the “sustainability” topic. Backstage is living a fast growth in adoption, maturity, and features, and part of its growth is about going beyond the current investments and investors. While we see the community growing with the current maintainers and investors, we would like to see more diversity in the core team. In addition, we believe that a truly successful open source project needs commercial ventures to continue to grow and thrive, and we are thinking of promoting initiatives for additional services specifically focusing enterprises and business use cases.

137
reviews/2021-Kyverno-annual.md Normal file
View File

@ -0,0 +1,137 @@
# Kyverno 2021 Annual Review
This is a Kubernetes ToC Annual Review for the [Kyverno](https://kyverno.io) project for 2021.
## Table of Contents
- [Background](#background)
- [DevStats](#devstats)
- [Maintainers](#maintainers)
- [Adoption](#adoption)
- [Project goals](#project-goals)
- [CNCF Membership](#cncf-membership)
- [Incubation](#incubation)
- [Project Links](#project-links)
## Background
Kyverno ("govern" in Greek) is a policy management solution designed for Kubernetes.
The main goal of the Kyverno project is to simplify Kubernetes configuration management using policies for security and automation. Kyverno makes it easy for Kubernetes administrators to write and manage Kubernetes policies and for Kubernetes workload owners (for example, developers) to consume policy results and address issues.
In addition to validating resources (in either audit or enforce modes), Kyverno has full support for mutating and generating Kubernetes resource and is often used to automate costly and error-prone handoffs across operations, security, and development roles.
Kyverno uses Kubernetes custom resource definitions for cluster-wide and namespaced policies, and the [Kubernetes Policy WG policy report](https://github.com/kubernetes-sigs/wg-policy-prototypes/tree/master/policy-report) for reporting policy results. Kyverno runs as an admission controller and as a standalone command-line tool.
Since Kyverno is focused on Kubernetes, it leverages Kubernetes patterns, idioms, and tools such as:
* owner references
* pod and pod controller relations
* structural schemas in OpenAPIv3
* strategic merge patches
Kyverno's focus on Kubernetes and its subsequent ability to leverage Kubernetes internals makes it intuitive and easy to use for Kubernetes administrators and operators.
Kyverno was accepted as a CNCF Sandbox project on [November 9th, 2020](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40/edit#gid=1136111842).
## DevStats
> Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.
The Kyverno DevStats dashboards can be found [here](https://kyverno.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m&viewPanel=4).
We are using the following metrics as key indicators of community health:
* [Stargazers](https://kyverno.devstats.cncf.io/d/81/community-health?orgId=1&var-repo_name=All&var-metric=Stargazers&var-table=swatchers&var-pref=all&var-met1=watch&var-met2=watch&from=now-1y&to=now): 331% annual growth from 524 -> 1735.
* [Issue Creators](https://kyverno.devstats.cncf.io/d/81/community-health?orgId=1&var-repo_name=All&var-metric=Issue%20creators&var-table=scommunity_health&var-pref=&var-met1=chealthissue&var-met2=&from=now-1y&to=now): 500% annual growth from 45 -> 225.
* [Code Committers](https://kyverno.devstats.cncf.io/d/81/community-health?orgId=1&var-repo_name=All&var-metric=Code%20committers&var-table=scommunity_health&var-pref=&var-met1=chealthcommit&var-met2=&from=now-1y&to=now): 500% annual growth from 18 -> 90.
* [Code Commenters](https://kyverno.devstats.cncf.io/d/81/community-health?orgId=1&var-repo_name=All&var-metric=Code%20commenters&var-table=scommunity_health&var-pref=&var-met1=chealthcomment&var-met2=&from=now-1y&to=now): 509% annual growth from 22 -> 112.
## Maintainers
Kyverno currently has 5 maintainers from 4 different companies:
| Maintainer | GitHub ID | Affiliation |
| -------------------- | --------------------------------------------- | ----------- |
| Chip Zoller | [@chipzoller](https://github.com/chipzoller) | Dell Technologies |
| Jim Bugwadia | [@JimBugwadia](https://github.com/JimBugwadia) | Nirmata Inc. |
| Marcel Muller | [@MarcelMue](https://github.com/MarcelMue) | Giant Swarm GmbH |
| Shuting Zhao | [@realshuting](https://github.com/realshuting) | Nirmata Inc. |
| Trey Dockendorf | [@treydock](https://github.com/treydock) | Ohio Supercomputer Center |
| Vyankatesh Kudtarkar | [@vyankyGH](https://github.com/vyankyGH) | Nirmata Inc. |
| Prateek Pandey | [@prateekpandey14](https://github.com/prateekpandey14) | Nirmata |
| Sambhav Kothari | [@samj1912](https://github.com/samj1912) | Bloomberg |
The maintainer list is managed in our [GitHub repository](https://github.com/kyverno/kyverno/blob/main/MAINTAINERS.md) along with our [governance policy](https://kyverno.io/community/).
## Adoption
Adopters who are publicly referenceable are listed in the [Kyverno GitHub repository ADOPTERS.md file](https://github.com/kyverno/kyverno/blob/main/ADOPTERS.md).
Kyverno adopters include:
**Projects**
* [Flux](https://github.com/fluxcd/flux2-multi-tenancy/tree/main/infrastructure/kyverno-policies)
* [OpenEBS](https://github.com/openebs/charts/tree/main/charts/openebs/templates/kyverno)
* [cert-manager](https://github.com/jetstack/cert-manager/tree/master/devel/addon/kyverno)
* [CNF WG tests](https://github.com/cncf/cnf-testsuite)
**Organizations**
* [Ohio Supercomputer Center](https://www.osc.edu/)
* [VSHN](https://www.vshn.ch/en/)
* [Coinbase](https://www.coinbase.com/)
* [Mandiant](https://www.mandiant.com/)
* [Giant Swarm](https://www.giantswarm.io/)
* [Vodafone Group Plc](https://www.vodafone.com/)
* [Deutsche Telekom](https://www.telekom.com/en)
* [Bloomberg](https://www.techatbloomberg.com/)
A list of companies providing commercial services and solutions for Kyverno is available [here](https://kyverno.io/support/).
## Project Goals
> How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
The main goals of the project have been in the following categories:
* **Complex policy support**: Several new features such as [JMESPath support](https://kyverno.io/docs/writing-policies/variables/), [API Server Lookups](https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-kubernetes-api-server-calls), and [foreach](https://kyverno.io/docs/writing-policies/validate/#foreach) have been introduced to allow declarative processing of complex policy logic.
* **Availability**: Kyverno has added the ability to support multiple replicas for fault-tolerance and increased availability in Release 1.4.0 (June 2021).
* **Scalability**: Several fixes and improvenents have been made to reduce memory usage and handle large clusters. This remains an on-going area of test and improvement.
* **Security**: Kyverno participated in the CNCF TAG Security [Security Pals](https://github.com/cncf/tag-security/issues/554) program. As a result, Kyverno has adopted recommended security best practices. The [Security](https://main.kyverno.io/docs/security/) section in the Kyverno documentation lists these and acts as a security guide for adopters.
* **Community and Awareness**: Kyverno has grown from initially having maintainers from a single company, to maintainers from multiple organizations. The community has also grown significantly as reflected by [DevStats](https://kyverno.devstats.cncf.io). While Kyverno awareness has grown, more work is needed to make the community fully aware of all of its features and capabilities.
> What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
1. **Scalability**: Kyverno is increasingly being used in large production clusters. We aim to dramatically improve scalability in the subsequent releases.
2. **Security**: In addition to current security processes, a goal for Kyverno is to improve software supply chain security and achieve [SLSA Level 4](https://slsa.dev/levels).
3. **Adoption**: We aim to continue growing Kyverno adoption. A survey conducted by Nirmata at KubeCon US 2021 showed Kyverno adoption is currently around 8%. Our goal is to exceed 30% adoption by Q4 2022.
## CNCF membership
> How can the CNCF help you achieve your upcoming goals?
Kyverno has benefited greatly from the CNCF and its community, especially in the areas of awareness and adoption. The Kyverno project has also participated in the [LFX Mentorship program](https://mentorship.lfx.linuxfoundation.org/#projects_all), KubeCon project office hours, and the Community Infrastructure Lab.
Some areas where we can use help are:
* Best practices for automated scale testing.
* A security assessment and guidance on fuzzing and other security best practices to improve the Kyverno security posture.
* Continued support for webinar, blogs, and other community activities to increase visibility and adoption.
* Add Kyverno to the Certified Kubernetes Security Specialist (CKS) examination and any other CNCF materials that reference the Open Policy Agent (OPA) project, to help drive awareness and promote fairness across projects.
## Incubation
> Do you think that your project meets the [criteria for incubation](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage)?
Yes. The Kyverno project team has started planning a proposal for incubation and plans to submit it in the next month. This work is tracked in [issue #2838](https://github.com/kyverno/kyverno/issues/2838).
## Project Links
- [Website](https://kyverno.io)
- [Github](https://github.com/kyverno)
- [Slack](https://slack.k8s.io/#kyverno)
- [Twitter](https://twitter.com/kyverno)

129
reviews/2021-OpenKruise-annual.md Normal file
View File

@ -0,0 +1,129 @@
# OpenKruise Sandbox Annual Review
## Background
[OpenKruise](https://openkruise.io) is an extended component suite for Kubernetes,
which mainly focuses on application automations, such as deployment, upgrade, ops and availability protection.
Most features provided by OpenKruise are built primarily based on CRD extensions.
They can work in pure Kubernetes clusters without any other dependencies.
Currently, OpenKruise primarily provides the following capabilities:
- **Advanced workloads**, which support not only the basic features that are similar to the upstream Workloads in Kubernetes, but also more advanced abilities such as in-place update, configurable scale/upgrade strategies, parallel operations.
- **Sidecar container management**, which defines, injects and even upgrades sidecar containers with no effect on application containers.
- **Multiple domain management**, which empowers workload to support multi-domain and elastic deployment, so that users can define the rules about how their applications should be deployed over different kinds of nodes, e.g., nodes across availability zones.
- **Enhanced operations**, such as restarting containers in-place, pre-downloading images on specific nodes, controlling containers starting priority in a Pod and distributing resources over multiple namespaces.
- **Application availability protection**, which can prevent unexpected Kubernetes resources deletion during cascading deletion and prevent application from disruption or SLA degradation in voluntary disruption scenarios.
### Alignment with CNCF
- OpenKruise was accepted as a CNCF Sandbox project on Nov 10, 2020.
## Development metrics
The OpenKruise devstats page and dashboards can be found [here](https://openkruise.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m&search=open).
- According to devstats, OpenKruise currently has [92](https://openkruise.devstats.cncf.io/d/22/prs-authors-table?orgId=1) contributors from [39](https://openkruise.devstats.cncf.io/d/5/companies-table?orgId=1)
companies. On average, there are [28 commits per month](https://openkruise.devstats.cncf.io/d/74/contributions-chart?orgId=1&var-period=m&var-metric=commits&var-repogroup_name=All&var-country_name=All&var-company_name=All&var-company=all&from=now-2y&to=now) contained within [18 merged PRs per month](https://openkruise.devstats.cncf.io/d/74/contributions-chart?orgId=1&var-period=m&var-metric=mergedprs&var-repogroup_name=All&var-country_name=All&var-company_name=All&var-company=all&from=now-2y&to=now).
- [New PRs in last year](https://openkruise.devstats.cncf.io/d/15/new-prs-in-repository-groups?orgId=1).
- A few highlights since the project joined CNCF:
- Number of contributors: 50+ -> **90+**
- Github stars: 1700+ -> **2800+**
- Github forks: 220+ -> **460+**
- Docker image Pulls: **5M+**
- Member of DingTalk group + Slack channel: 600+ -> **1000+**
We have held bi-weekly community meetings and the meeting notes and agenda can be found in [here](https://shimo.im/docs/gXqmeQOYBehZ4vqo).
## Maintainers
[The community membership guidance](https://github.com/openkruise/community/blob/master/community-membership.md) has been established for a long time. Based on this, we have significantly expanded our maintainers. Currently, we have [seven maintainers](https://github.com/openkruise/community/blob/master/MAINTAINERS.md) from five organizations, which demonstrates the growth of the community considering the fact that we only have three maintainers (all from Alibaba) initially.
| Maintainer | GitHub ID | Affiliation |
| ---------------- | --------------------------------------------- | ----------- |
| Fei Guo | [Fei-Guo](https://github.com/Fei-Guo) | Alibaba |
| Siyu Wang | [FillZpp](https://github.com/FillZpp) | Alibaba |
| Zhen Zhang | [furykerry](https://github.com/furykerry) | Alibaba |
| Robert Everson | [reverson](https://github.com/reverson) | Lyft |
| Henry Wang | [henrywangx](https://github.com/henrywangx) | Tencent |
| Shanjie Han | [hantmac](https://github.com/hantmac) | MeiTuan |
| Yan Shi | [shiyan2016](https://github.com/shiyan2016) | Trip |
## Project adoption
The public adopters that used OpenKruise in production can be found [here](https://github.com/openkruise/kruise/issues/289). Examples include:
- **DouyuTV (China)**: Using Kruise for managing statefulset applications. They need parallel updates.
- **Sto (China)**: Using Kruise for managing statefulset applications, They need inplace upgrades.
- **Boss直聘 (China)**: sidecar,cloneset,statefulset for Corporate Paas.
- **hangyinxiaofei (China)**: sidecar,cloneset,statefulset for Corporate Paas.
- **vanyitech (China)**: Using Kruise for managing cloneset applications, they need inplace upgrades. Using BroadcastJob to clean images.
- **Lyft (US)**: Using Kruise CloneSets and bin packing for selective downscaling of stateful nodes.
- **Ctrip (China)**: Using CloneSet and AdvanceStatefulSet for managing stateless and stateful apps. They need inplace and partial updates.
- **Dmall (China)**: Advance HPA, In-Place Update, Sidecar management, etc.
- **Bringg (Israel)**: Advanced DaemonSet, to solve load balancer connection to api gateway running with daemonset.
- **xiaohongshu (China)**: Using CloneSet and BroadcastJob for managing stateless apps and async job.
- **bixin (China)**: Using CloneSet and BroadcastJob for managing stateless apps and async job.
- **VIPKID (China)**: Using BroadcastJob for managing clusters.
- **zhangmen (China)**: Using CloneSet and AdvanceStatefulSet to deploy apps on production env. They need inplace and partial updates.
- **ihomefnt (China)**: Using sidecarset to inject container.
- **Arkane Systems (US)**: Using BroadcastJob/AdvancedCronTab for periodic per-node tasks and cleanup; using SidecarSet to inject local maintenance containers.
- **永辉科技中心 (China)**: Using CloneSet and SidecarSet to in-place upgrade and manage sidecar pods.
- **OPPO (China)**: Using Kruise for managing large-scale statefulsets to in-place update.
- **Spectro Cloud (US)**: Using Kruise for managing periodic node actions.
- **Suning (China)**: Using CloneSet and SidecarSet to manage stateless apps and sidecar.
- **Deepexi (China)**: Using Kruise for managing large-scale applications and sidecars.
- **哈啰出行 (China)**: In-Place Update, Sidecar management, etc.
- **joyy (China)**: Using CloneSet and AdvanceStatefulSet for managing stateless and stateful apps.
- **Mobvista (China)**: Using Kruise for log collect sidecarsets and manage stateless cloneset apps.
- **深圳凤凰木网络有限公司 (China)**: Using CloneSet for managing stateless apps.
- **xiaomi (China)**: Using CloneSet for stateless apps.
- **Netease (China)**: Using SidecarSet to in-place upgrade and manage sidecar pods.
- **MeiTuan (China)**: Using CloneSet and AdvanceStatefulSet for managing stateless and stateful apps.
- **Shopee (China)**: Using CloneSet for stateless apps.
- **Esign (China)**: Using sidecarSet for sidecar container.
- **Wholee (China)**: Using CloneSet for managing stateless apps.
## Project goals
When developing OpenKruise, we aim to relieve the pain of managing large scale cloud native applications in Kubernetes for developers and cluster operators in production environments. The provided features and solutions are expected to be easily integratable for existing Kubernetes use cases. In the past year, we roughly followed three month release cycle and have accomplished the following development goals:
- Release cadence: 4 minor and 1 major releases. The latest release is v1.0.0.
- Key features added to the project (complete changelog can be found in [here](https://github.com/openkruise/kruise/blob/master/CHANGELOG.md)):
- 0.7.0
- New workload: AdvancedCronJob, which supports multiple kinds of job template.
- Promote Advanced StatefulSet API to v1beta1.
- 0.8.0
- A new component named kruise-daemon, which will be deployed on every node.
- New CRDs: NodeImage and ImagePullJob to support pre-download images on specific nodes.
- Refactor the controller and webhook for SidecarSet.
- 0.9.0
- New feature: ContainerRecreateRequest, which supports restarting containers in existing pods.
- New feature: Deletion Protection, which protects Kubernetes resources from the cascading deletion mechanism.
- 0.10.0
- New feature: PodUnavailableBudget, which can achieve the effect of preventing ALL application disruption or SLA degradation, including pod eviction, deletion, inplace-update and so on.
- New feature: WorkloadSpread, which supports to constrain the spread of stateless workload, which empowers single workload the abilities for multi-domain and elastic deployment.
- 1.0.0
- InPlace Update for container environments.
- Distribute resources over multiple namespaces.
- Container launch priority.
- Kubectl-kruise command line tool.
We are running our project in a fairly open model so that we can react to the needs of our community promptly. In addition, we have recently introduced a [roadmap](https://github.com/openkruise/kruise/projects/2) page in github so that the community members can easily track where we are going. There are still quite a few critical and high demanding features that are under development, including but not limited to the following:
- A new CRD named PodMarker to mark pods by number, labels, nodes, probes, etc.
- Decoupled liveness probe which supports restart containers on failure with limited rate.
- Binding nodes for statefulset pods after being recreated.
- Enhanced application rollout for traffic shifting and batch upgrades.
Besides, we have refactored [OpenKruise website](https://openkruise.io/) using Docusaurus v2 and tidy the documents in it this year. We plan to add more examples and best practices to help newcomers learn and use OpenKruise more easily.
OpenKruse have been integrated by several other open source projects.
- [KubeVela](https://kubevela.io/), a modern application delivery platform and CNCF Sandbox project, has provides [templates to work with OpenKruise workloads](https://github.com/oam-dev/kubevela/tree/master/vela-templates/addons/kruise).
- [MOSN]](https://mosn.io/en/), a popular cloud-native network proxy in China, is working on [using SidecarSet of OpenKruise to hot upgrade the proxy container](https://github.com/mosn/mosn.io/pull/166).
We are looking for more cross community collaborations within and outside of CNCF.
## How the CNCF can help to achieve the upcoming goals
- More channels to advocate the project within CNCF and even to other foundations.
- Writing support for project documents.
## Incubation readiness
- Yes, we are preparing for the incubation proposal.

212
reviews/2021-Pravega-annual.md Normal file
View File

@ -0,0 +1,212 @@
# Pravega.io Sandbox 2021 Annual Review
## Table of Contents
- [Project Devstats](#project-devstats)
- [Maintainers](#maintainers)
- [Adoption](#adoption)
- [Project Performance](#project-performance)
- [Open Governance](#open-governance)
- [Releases & Features](#releases--features)
- [Open Source](#open-source)
- [Community Outreach](#community-outreach)
- [Blog posts](#blog-posts)
- [Hackathons](#hackathons)
- [Conference presentations](#conference-presentations)
- [Current Goals](#current-goals)
- [Help with Goals](#help-with-goals)
- [Incubation](#incubation)
## Project Devstats
> Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.
The Pravega GitHub organization was active across 30 repositories in 2021, including:
- **Core Pravega**: The code base for the streaming storage engine, including the Java client, a CLI and long-term storage adapters;
- **Connectors**: Apache Flink, Apache Spark, Presto, Trino, GStreamer;
- **Helm charts and operators**: For Pravega, ZooKeeper, BookKeeper;
- **Additional client bindings**: For Rust and Python;
- **Schema Registry**: To enable schema management;
- **Samples**: Code samples for various components in the GitHub organization.
In 2021, the Pravega organization saw around 1,000 PRs, among which about 500 are in Pravega alone.
GitHub Forks and Stars have increased by 22% for Pravega repo alone. Stars have increased by 25% across all repositories.
| Metric (all repos) | Jan. 3rd, 2021 | Jan. 9th, 2022 | YoY change |
|--------------------|----------------|----------------|------------|
| Stargazers | 1356 | 1693 |25% increase|
| Forks | 280 | 350 |25% increase|
| Open Issues & PRs | 424 | 231 |46% decrease|
This year saw 34 new contributors across all repositories.
https://pravega.devstats.cncf.io/
## Maintainers
> How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)
We have organized contributors with write access into two levels. The Steering Committee comprises the contributors that manage the organization and map to the CNCF maintainers. Committers have access to groups of repositories that we organized into: Core, Ecosystem, Operators, Integration and Tools.
Maintainers file: https://github.com/pravega/.github/blob/main/MAINTAINERS
Number of maintainers (Steering Committee): 5
Number of organizations for maintainers: 3 (Dell, Wheels Up, Amazon)
Number of committers: 28
## Adoption
> What do you know about adoption, and how has this changed since your last review / since you joined Sandbox? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.)
One end-user company has joined the project and is increasing their contributions, having added support for Prometheus metrics as a recent major contribution.
This year has seen significant adoption of and commitment to Pravega internal to Dell Technologies, especially in the realms of storage products, edge sensor collection, video analytics and AI.
Pravega remains vital to Dell’s [Streaming Data Platform](https://www.delltechnologies.com/en-us/storage/streaming-data-platform.htm) product, where Pravega is seeing significant growth in the edge, with use cases having thousands of edge deployments.
**Data Flow from Sensors to the Edge and the Cloud using Pravega**<br>
https://cncf.pravega.io/blog/2021/03/23/data-flow-from-sensors-to-the-edge-and-the-cloud-using-pravega/
Pravega’s ZooKeeper Operator continues to see broad adoption, used by [Banzai Cloud Kafka Operator](https://banzaicloud.com/docs/supertubes/kafka-operator/install-kafka-operator/#install-zookeeper), [Apache Solr Operator](https://github.com/apache/solr-operator/blob/master/example/dependencies/zk_operator.yaml), [Mesosphere](https://docs.d2iq.com/dkp/kommander/2.1/workspaces/applications/catalog-applications/dkp-applications/zookeeper-operator/), [Tencent BlueKing Container Service](https://github.com/Tencent/bk-bcs/blob/master/install/kubernetes/zookeeper-operator.yaml), [KOARCH.de](https://github.com/janstrohschein/KOARCH/tree/master/Big_Data_Platform/Kubernetes/Kafka_Broker#zookeeper), and has seen contributions from developers at Fortune 500 & Top 100 Fastest Growing companies.
## Project Performance
> How has the project performed against its goals since the last review? (We won’t penalize you if your goals changed for good reasons.)
**2021 Milestones:**
- Open governance instituted
- Frequent major releases containing new features and new integrations
- External open source contributions on the rise
- Community outreach programs established
### Open Governance
Committers have been organized into 4 teams: Core, Operators, Ecosystem, and Integration & Tools. Pravega committer teams manage a total of 43 repositories. Open governance has been instituted following a model inspired by Apache projects: https://github.com/pravega/.github/blob/main/governance.md
### Releases & Features
Pravega has made steady progress closely following its published roadmaps through regular major and minor releases: 0.8.1, 0.9.0, 0.9.1, 0.10.0, 0.10.1 and 0.10.2.
Features enabled by these releases include performance improvements, Simplified Long Term Storage plugin system, Consumption Based Retention policies, Java 11 support, improved authorization, Rust and Python clients, improved test reliability, Stream Tags, Key Value Tables 2.0, Health Check, CLI improvements, TLS 1.3.
### Open Source
Open source drivers for Pravega have been added to OpenMessaging Benchmark, Debezium, and Project Alvarium. The Akka Alpakka library has expanded to support Key Value Tables. A new ZIO library was prototyped. Connectors to Presto and Trino were released.
**OpenMessaging Benchmark Pravega Driver**<br>
PR: https://github.com/openmessaging/benchmark/pull/199<br>
README: https://github.com/openmessaging/benchmark/tree/master/driver-pravega#pravega-benchmarks
**Debezium Server Pravega Sink**<br>
PRs: https://github.com/debezium/debezium/pulls?q=is%3Apr+author%3Aderekm+is%3Aclosed<br>
Docs: https://debezium.io/documentation/reference/operations/debezium-server.html#_pravega
**Project Alvarium Stream Provider (Alvarium is a Stage 1 LF Edge project)**<br>
Website: https://www.lfedge.org/projects/alvarium/<br>
Code: https://github.com/project-alvarium/alvarium-sdk-java/blob/main/src/main/java/com/alvarium/streams/PravegaStreamProvider.java
**Alpakka Pravega Connector Key Value Tables support**<br>
PR: https://github.com/akka/alpakka/pull/2651<br>
Docs: https://doc.akka.io/docs/alpakka/current/pravega.html (docs will reflect KVT support in Alpakka’s next release)
**ZIO Pravega Connector**<br>
GitHub: https://github.com/cheleb/zio-pravega<br>
README: https://github.com/cheleb/zio-pravega/blob/master/README.md#pravega-zio
**Presto and Trino Connectors**<br>
GitHub: https://github.com/pravega/presto-connector<br>
Getting Started: https://github.com/pravega/presto-connector/tree/main/getting-started
### Community Outreach
Pravega Community meetings were founded under Cloud Native Community Groups:<br>
https://community.cncf.io/pravega-community/
Four community meetings overviewing new features and connectors were held between March and September:<br>
https://www.youtube.com/playlist?list=PLgODz_jrU0amcesAG6NngJxWVWT1znYYX
One community meeting was held in China:<br>
https://www.youtube.com/watch?v=MUyuEcKPBzg
Meetup presentations are providing content for Pravega’s YouTube channel:<br>
https://www.youtube.com/channel/UCiEkLCWdnjSpub76ZEZcdqw
Dell QE had an engagement with LitmusChaos community to exhibit how fault injection tests are used to validate Pravega:<br>
https://youtu.be/EU_g8cKa1G8
Dell China and PingCAP collaborated on an evaluation of Change Data Capture using Pravega, TiDB & Flink SQL:<br>
https://asktug.com/t/topic/92873<br>
https://pingcap.medium.com/building-a-real-time-data-warehouse-with-tidb-and-pravega-a44fba92b3fa
We joined Presto Technical Steering Committee and Trino Community Broadcast meetings to review the new Pravega Presto/Trino connector:<br>
Presto TSC meeting: https://youtu.be/4EZrZ4vaAys<br>
Trino Community Broadcast: https://trino.io/episodes/28.html
### Blog posts
In 2021, the following blog posts were published:
**When Speed meets Parallelism – Pravega performance under parallel streaming workloads**<br>
https://cncf.pravega.io/blog/2021/03/10/when-speed-meets-parallelism-pravega-performance-under-parallel-streaming-workloads/
**Data Flow from Sensors to the Edge and the Cloud using Pravega**<br>
https://cncf.pravega.io/blog/2021/03/23/data-flow-from-sensors-to-the-edge-and-the-cloud-using-pravega/
**Pravega Flink Connector 101**<br>
https://cncf.pravega.io/blog/2021/11/01/pravega-flink-connector-101/
### Hackathons
Unbounded Hackathon was held in English for US/APAC:<br>
https://unboundedhackathon.com/
ITMO University hackathon held in Russia:<br>
https://news.itmo.ru/en/announce/65679/
Pravega China Hackathon was held in China:<br>
https://mp.weixin.qq.com/s/JvLDz4sTq32hOQcnyb0IDg
Flink Forward Asia Hackathon (Flink & Pravega Hackathon), Pravega community was the major sponsor:<br>
https://tianchi.aliyun.com/competition/entrance/531936/introduction
### Conference presentations
Asia Innovation Summit presentation:<br>
https://www.youtube.com/watch?v=l4uXgHOn-xQ
NASSCOM presentation:<br>
https://www.youtube.com/watch?v=gspgqAFJmGQ
StrangeLoop presentation:<br>
https://www.youtube.com/watch?v=AI1M7Wr4_6w
Flink Forward Asia (FFA) 2021, one keynote session and one session on Flink ecosystem from Pravega was presented:<br>
https://flink-forward.org.cn/
“Flink & Pravega” technical whitepaper, a certified joint solution between Flink and Pravega, was published in FFA 2021:<br>
https://flink-learning.org.cn/article/detail/4c6f8c1bf87f3a83bac266690f07a0bb
https://flink-learning.org.cn/article/detail/5a7e33f36930c5f6da328aea88102fb9
PingCAP DevCon 2021 presentation:<br>
https://www.bilibili.com/video/BV1D64y1W71M/
## Current Goals
> What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
Working on new features and tools in the 0.11 release and beyond. https://github.com/pravega/pravega/blob/master/documentation/src/docs/roadmap.md
Focusing on popularizing Pravega and increasing its adoption. Generating mixed-media content at all skill levels, especially beginner and advanced material. Disseminating content more broadly across social media by leveraging individual networks.
New integrations to broaden Pravega’s applicability as a component in off-the-self solutions.
## Help with Goals
> How can the CNCF help you achieve your upcoming goals?
There are a few options:
- **Streaming events**: Having a Day 0 event in the 2022 KubeCon series, “Cloud Native Streaming Day,” with other streaming-oriented projects: Pravega, Strimzi, NATS, gRPC, CloudEvents, etc;
- **Documentation**: Support for content generation of technical documentation. We are converting documentation from MkDocs to Docusaurus, combining docs across several repos into a single docs site, allowing for advanced formatting such as doc variables (e.g., version numbers). As we continue to improve our docs site, additional assistance is desirable;
- **Test infrastructure**: We need always-on Kubernetes clusters to run our system tests, longevity tests and Litmus Chaos tests in the open. Pravega codebase includes a suite of system tests, but these are presently used to confirm releases internally. Whether via Prow infra or the cncf.ci initiative, assistance in gaining access to test execution resources at the CNCF would help us move these validations into the public realm.
## Incubation
> Do you think that your project meets the criteria for incubation?
No, only one qualifying end-user presently.

131
reviews/2021-kuma-annual.md Normal file
View File

@ -0,0 +1,131 @@
# Kuma Sandbox Annual Review
## Table of Contents
- [Background](#background)
- [Alignment with Cloud Native](#alignment-with-cloud-native)
- [Year in Review](#year-in-review)
- [Annual Review Contents](#annual-review-contents)
- [Project Links](#project-links)
## Background
[Kuma](https://kuma.io) is a modern control plane for Service Mesh and Microservices. It can run and be operated natively across both Kubernetes and VM environments, making it easy to adopt by every team in the organization with the goal of accelerating both Kubernetes and Service Mesh adoption.
By bundling the Envoy proxy as the underlying data-plane technology, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs, while at the same time providing a RESTful API, a native CLI tool and a built-in GUI that can be used to better integrate Kuma with the rest of the organization.
While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networing stack.
**Kuma was accepted as a CNCF Sandbox project on June, 2020.**
- [Sandbox Proposal](https://github.com/cncf/toc/blob/main/proposals/sandbox/kuma.md)
- Kuma falls in the scope of [CNCF Network tag](https://github.com/cncf/tag-network).
## Year in Review
- Since June 2020 Moved from 0.6.0 to 1.4.0
- Version 1.0.0 released 24/11/2020
- 28 releases in total since incubation.
- 1759+ commits; 1.8k+ stars; 400+ forks; 220+ contributors
- Key Features Added: externalService, built in DNS, GUI refresh, IPv6 support, permissive mTLS...
## Annual Review Contents
### Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.
- [New PRs last 1 year](https://kuma.devstats.cncf.io/d/15/new-prs-in-repository-groups?orgId=1&from=1586448000000&to=1622476799000&var-period=w&var-repogroup_name=All)
- [Commits Repository Groups last 1 year](https://kuma.devstats.cncf.io/d/2/commits-repository-groups?orgId=1&from=now-1y&to=now&var-period=w&var-repogroups=All)
- Community growth
- Entered CNCF sandbox in June 2020
- Continuous momentum
- Num of Contributors: 18 => **78+**
- Github Stars: 1400+ => **2616+**
- Github Forks: 173+ => **297+**
### How many maintainers do you have, and which organizations are they from? [OWNERS.md](https://github.com/kumahq/kuma/blob/master/OWNERS.md)
Initial maintainers
* Jakub Dyszkiewicz ([jakubdyszkiewicz](https://github.com/jakubdyszkiewicz)) (jakub.dyszkiewicz@konghq.com) Kong
* Ilya Lobkov ([lobkovilya](https://github.com/lobkovilya)) (ilya.lobkov@konghq.com) Kong
* Marco Palladino ([subnetmarco](https://github.com/subnetmarco)) (marco@konghq.com) Kong
New in the Year
* Austin Cawley-Edwards([austince](https://github.com/austince)) (austin.cawley@gmail.com) Ververica
* Bart Smykla ([bartsmykla](https://github.com/bartsmykla)) (bartek@smykla.com) Kong
* Charly Molter ([lahabana](https://github.com/lahabana)) (charly@molter.io) Kong
* James Peach ([jpeach](https://github.com/jpeach)) (james.peach@konghq.com) Kong
* Mike Beaumont ([michaelbeaumont](https://github.com/michaelbeaumont)) (michael.beaumont@konghq.com) Kong
* Nikolay Nikolaev ([nickolaev](https://github.com/nickolaev)) (nicknickolaev@gmail.com) Juniper Networks
* Paul Parkanzky ([parkanzky](https://github.com/parkanzky)) (paul.parkanzky@konghq.com) Kong
### What do you know about adoption, and how has this changed since your last review / since you joined Sandbox? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.)
While it's hard to track the global usage (especially without telemetry) we know that Kuma is being used in production across 40+ large enterprise organizations worldwide that decided to engage with Kong (and counting), and has been used by approximately 1000+ organizations worldwide in the last 12 months, including Sabre, American Airlines, and several large financial institutions.
### How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
We've released a total of 28 releases.
At sandbox time goals included:
* Support for L7 HTTP routing policies (in addition to the existing L4 routing policy)
* Support for L7 gRPC routing policies (in addition to the existing L4 routing policy)
* Discussing roadmap for SMI integration (most requested feature on GitHub)
* Introducing pluggable backends for mTLS, logging and tracing policies
* Adding support for multi-cluster Kubernetes deployments
* Support for traffic shadowing and auto-retries
* Support for L7 HTTP traffic permissions (in addition to the existing L4 traffic permission policy)
* Support for L7 gRPC traffic permissions (in addition to the existing L4 traffic permission policy)
* Support for L7 gRPC logging (in addition to the existing L4 traffic log policy)
* GUI wizards for every entity (in addition to Mesh and Dataplane entities)
What we've shipped since:
* Newest GUI with support for all entities
* ExternalService support
* Big performance improvements
* Transparent Proxy for non k8s use-cases
* IPv6 support
* mTLS permissive mode to ease migration to Kuma
* Some policy support for gRPC and HTTP
* DNS Proxy with configurable DNS entries to simplify discovery in the serviceMesh
* Migrated all issues to github issues and setup public triage meeting to provide better visibility to the community.
* Native integration with [prometheus](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kuma_sd_config) to make Kuma even more cloud native.
### What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
- Technical
- Performance improvements and qualification (we want to demonstrate that Kuma scales to O(10K) dataplanes and O(100) zones)
- Rewrite of policy selector to simplify even more Kuma's UX and unblock some features (some L7 policies are currently blocked by this)
- Simplify deployment topology for multi-zone setups.
- Community
- Further, grow the number of contributors
- Move to a more predictable versioning policy
- Define a security process
### How can the CNCF help you achieve your upcoming goals?
- We need more speaking and marketing opportunities to help attract more contributors and user adoptions.
- We would like to reintroduce a way to follow feature usage and installation count as it's hard to track adoption without this.
- We could use with some help with some technical writing.
### Do you think that your project meets the [criteria for incubation](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage)?
No for the following reasons:
- We would like to be 2.0 before incubation.
- We still need to clarify our release policy and our security process.
## Project Links
- [Website](https://kuma.io/)
- [Github](https://github.com/kumahq/kuma)
- [Slack](https://chat.kuma.io)
- [Twitter](https://twitter.com/kumamesh)
- [Issue Tracker](https://github.com/kumahq/kuma/issues)

133
reviews/2022-Athenz-annual.md Normal file
View File

@ -0,0 +1,133 @@
# Athenz-2022-Annual Review
This is the annual review for the [Athenz](https://athenz.io) project for 2022.
## Table of Contents
- [Background](#background)
- [DevStats](#devstats)
- [Maintainers](#maintainers)
- [Adoption](#adoption)
- [Project goals](#project-goals)
- [CNCF Membership](#cncf-membership)
- [Incubation](#incubation)
## Background
Athenz is an open source platform for X.509 certificate based service authentication and fine-grained
access control in dynamic infrastructures. It enables zero trust core principles like traffic encryption,
authentication, authorization, dynamic trust and least privilege access. Athenz was accepted as a
CNCF Sandbox project on January 26th, 2021. It provides the following two major features:
* X.509 Certificate Based Authentication
- Service identity in the form of short-lived X.509 certificates to all workloads deployed in
private or public clouds.
* Fine-grained Authorization
- Authorize all authenticated clients using fine-grained role-based (RBAC) access control with
industry standard OAuth2 JWT access tokens.
## DevStats
Athenz DevStats dashboard [here](https://athenz.devstats.cncf.io/d/8/dashboards?orgId=1&viewPanel=2&from=now-1y&to=now-1h&refresh=15m)
shows a consistent rate of commits throughout the year. The significant percentage of code commits is
from the core maintainers, most of whom work at Yahoo as most of the products at Yahoo such as Mail,
Sports, Finance and Ads are heavily integrated with Athenz and the team receives a large number of
feature requests and enhancements from those product teams.
The maintainers prefer a periodic release of Athenz servers and libraries as opposed to few releases
with large number of changes. When Athenz joined CNCF as a sandbox project, we had just released the
1.10.4 version of the product. In the last year we’ve released 45 minor versions and the latest Athenz
release now is [1.10.49](https://github.com/AthenZ/athenz/blob/master/CHANGELOG).
## Maintainers
Athenz currently has [3 core maintainers](https://github.com/AthenZ/athenz/blob/master/MAINTAINERS), all from Yahoo:
| Maintainer | GitHub Username | Company |
| ---------------- | --------------------------------------------- | ----------- |
| Henry Avetisyan | [@havetisyan](https://github.com/havetisyan) | Yahoo |
| Abhijeet Vaidya | [@abvaidya](https://github.com/abvaidya) | Yahoo |
| Ofer Levi | [@OferLevi85](https://github.com/OferLevi85) | Yahoo |
The Athenz Auth0 and Prometheus plugin subprojects have the [following 5 maintainers](https://github.com/AthenZ/athenz-metric-prometheus/blob/master/MAINTAINERS), all from Yahoo! Japan Corporation.
| Maintainer | GitHub Username | Company |
| ------------- | ------------------------------------------ |--------------|
| Windz Fan | [@WindzCUHK](https://github.com/WindzCUHK) | Yahoo! Japan |
| Tatsuya Yano | [@tatyano](https://github.com/tatyano) | Yahoo! Japan |
| Seitaro Suno | [@ssunorz](https://github.com/ssunorz) | Yahoo! Japan |
| Takayuki Ino | [@falz-tino](https://github.com/falz-tino) | Yahoo! Japan |
| Kyo Fujisaki | [@kyfujisa](https://github.com/kyfujisa) | Yahoo! Japan |
Yahoo! Japan is also planning to contribute its Athenz Go-based authorization sidecar to the Athenz project as well.
The Athenz HashiCorp Terraform Plugin subproject has the following [core maintainer](https://github.com/AthenZ//terraform-provider-athenz/blob/master/MAINTAINERS) from Yahoo.
| Maintainer | GitHub Username | Company |
| ---------------- | ---------------------------------------------- | ----------- |
| Dvir Guttman | [@dvirguttman](https://github.com/dvirguttman) | Yahoo |
Athenz Governance Policy is available in our [Github repository](https://github.com/AthenZ/athenz/blob/master/GOVERNANCE.md).
## Adoption
Unfortunately we were not keeping track of our adopters and we just created an [Adopters file](https://github.com/AthenZ/athenz/blob/master/ADOPTERS.md)
in our Github Repository to start to track publicly referenceable uses of the projects.
At this time we’re aware of Athenz being used in a production environment in two companies:
Yahoo and Yahoo Japan. Athenz is heavily supported and used at both companies. At Yahoo, it
is used to provide an x.509 identity to all of our workloads deployed within our Kubernetes
clusters, On-prem data centers and in AWS enabling those components to enforce mutual TLS
authentication for all service to service communications. Athenz Authorization Token Service
enables Yahoo service to utilize TLS bound OAuth2 tokens to implement role based authorization support.
## Project Goals
When Athenz joined CNCF as a sandbox project, its goals were to add additional functionality
and increase adoption. We have added a significant number of new features in the last year. Some notable one are:
* Support Athenz as an OIDC Provider in Kubernetes
* Improve operability of Athenz with Kubernetes Service Mesh by introducing Envoy SDS support for service x.509 certificates.
* An official [Athenz HashiCorp Terraform Provider](https://registry.terraform.io/providers/AthenZ/athenz/latest)
* Support publishing domain changes as events through an interface. An implementation of
[Apache Pulsar](https://pulsar.apache.org) was delivered as part of the feature
* Supporting of Tags (key/value pairs) for domains, roles and groups.
* Support for multi-version authorization policies providing the capability to quick and easy
rollback to a previous version if necessary.
* Deliver OAuth 2.0 Rich Authorization Requests feature based on [Internet Draft](https://www.ietf.org/id/draft-ietf-oauth-rar-10.html)
The full list of features and changes are available in our [roadmap](https://github.com/AthenZ/athenz/blob/master/roadmap.md)
and in our [release change logs](https://github.com/AthenZ/athenz/releases/tag/v1.10.49)
One major area we have been focusing on last year is micro-segmentation support based on service identities.
We’re experimenting with eBPF technology to provide such capabilities within Athenz.
To increase adoption we were hoping that we would get a contribution to provide support for
Google Cloud Platform since Athenz already provides support for providing workloads running in AWS
and Azure with service identity x.509 certificates. We recently were notified that
[Vespa](https://vespa.ai) team will likely be contributing support for the Google Cloud Platform.
One final area that we’ll be focusing on is initial setup. Since a typical setup of Athenz
requires installations and coordination of several components: Management Service, Token Service,
UI, Authentication Authority and Certificate Signer, we’ve heard from several users through
our mailing list and/or slack channel that they’re looking for a simplified installation
setup that would allow users bring up a server quickly to determine if it satisfies their
requirements thus can be considered to be deployed at their companies.
We believe once we have support for all three major cloud providers along with micro-segmentation
support, and a simplified installation setup, we’ll be in a better position to focus on
increasing adoption of Athenz.
## CNCF membership
Athenz has mainly benefited in the area of awareness from inclusion in the CNCF as a sandbox
project. This is an area that we’d like to get continued support. During one of the End-User
Community Calls we were advised to present and request a security review from the Security
TAG which we are planning to do once we finalize our micro-segmentation based on service
identities feature.
## Incubation
At this time Athenz is not ready to apply for incubation due to limited adoption. It is our
goal to improve our adoption and get more consistent contributions from additional
organizations before applying for incubation.

171
reviews/2022-Network Service Mesh-annual.md Normal file
View File

@ -0,0 +1,171 @@
# Network Service Mesh Sandbox Annual Review 2022
## Table of Contents
* [Background](#background)
* [Alignment with Cloud Native](#alignment-with-cloud-native)
* [Highlights of Last Year](#highlights-of-last-year)
* [Annual Review Questions](#annual-review-questions)
* [Project Links](#project-links)
## Background
Network Service Mesh provides a Hybrid/Multi-cloud IP Service mesh. Inspired by L7 service meshes like Linkerd, Istio,
and others, Network Service Mesh maps the concept of a service mesh from L7 payloads to L2/L3 payloads.
Network Service Mesh recognizes and respects that the existing Kubernetes Networking provides excellent service for
common developer use cases.
Network Service Mesh requires no changes to the CNI plugin being used, or to Kubernetes itself to function.
It runs as an additional layer of infrastructure on top of stock out of the box Kubernetes.
When Network Service Mesh is installed on a K8s cluster, sophisticated network connectivity is simplified for the developer.
They need only specify, in an annotation on their Pod, the name of the Network Service they wish to consume,
such as "db-replication". Network Service Mesh will ensure
that Network Service is available to their Pods (not to the cluster as a whole) without using CNI. Standard
Kubernetes Networking is still provided by CNI. Network Service Mesh takes care to insure that it is completely
non-conflicting with Kubernetes Networking.
### Example: **db-replication**
Database workloads across multiple K8s clusters in different public clouds and on prem can
connect to a vL3 Network Service that exists solely for the purpose of database replication, and only has
database workloads that need to participate in such replication connected to it. This is done declaratively. The developer
simply adds a simple one line annotation to the Pod spec for their DB Pods.
## Alignment with Cloud Native
### Loose Coupling
IP Networking has traditionally been strongly coupled to the runtime domain (K8s cluster, VIM, datacenter, etc).
Where a workload ran determined what networking was available to it and the semantics of what networking features
it could receive.
Network Service Mesh allows workloads to be 'loosely coupled' to the Network Service (or Network Services) that are
relevant to their particular work independent of the environment they are running in. Workloads running in different
clusters hybrid/multi-cloud scenarios can connect to a common Network Service that provides the networking features
needed for their particular collaboration.
Network Service Mesh does this without disturbing (and taking care not to break) the existing networking provided
by the runtime. K8s Networking via CNI is untouched, and continues to work as expected.
Network Service Mesh makes IP networking itself Cloud Native by loosely coupling with the existing
immutable infrastrcture in K8s to deliver whatever non-standard Networking needs a workload has with minimal toil.
NSM is a complement to higher level L7 Service Meshes (Linkerd), providing an additional
connectivity,security and observability at lower layers.
### Minimal Toil
The Network Service Mesh enabled developers access Network Services with minimal toil:
* Developers ask for what Network Service they want by name
* Developers can add metadata to their request for a Network Service with labels.
* Developers simply get the Network Service they asked for
Developers never have to know or think about 35 year old legacy Networking concepts like:
* Subnets
* Interfaces
* Routes
* IPAM
### Immutable Infrastructure
Network Service Mesh shifts IP networking from being 'Infrastructure' to being a selection of 'Network Services'.
This allows infrastructure to remain immutable while meeting a much wider variety of requirements.
By scoping the selection of 'Network Services' to the granularity of workloads (rather than clusters), Network Service Mesh
allows different workloads to consume different Network Services that could be conflicting if forced into cluster level
infrastructure.
## Highlights of Last Year
### Community
In the last year Network Service Mesh has had contributions from:
* [30 contributors](https://networkservicemesh.devstats.cncf.io/d/22/prs-authors-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All)
* [9 Organizations](https://networkservicemesh.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=commits)
Including:
* Cisco
* Ericsson Software Technology
* Red Hat
### Releases
Network Service Mesh had three release in the last year:
* [v1.0.0](https://networkservicemesh.io/docs/releases/v1.0.0/) - Jun 19, 2021
* [v1.1.0](https://networkservicemesh.io/docs/releases/v1.1.0/) - Nov 28, 2021
* [v1.2.0](https://networkservicemesh.io/docs/releases/v1.2.0/) - Feb 15, 2021
## Annual Review Questions
1. _Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats._
[Network Service Mesh Devstats](https://networkservicemesh.devstats.cncf.io/)
Highlights:
* [30 contributors](https://networkservicemesh.devstats.cncf.io/d/22/prs-authors-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All)
* [9 Organizations](https://networkservicemesh.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=commits)
Including:
* Cisco
* Ericsson Software Technology
* Red Hat
* [Commits](https://networkservicemesh.devstats.cncf.io/d/2/commits-repository-groups?orgId=1&from=now-1y&to=now&var-period=d7&var-repogroups=All)
have remainded strong in the last year.
2. _How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)_
Network Service Mesh has five top level MAINTAINERS:
* Andre Sobolov (Xored)
* Ed Warnicke (Cisco)
* Frederick Kautz (Anthem)
* Nikolay Nikolaev (Juniper)
* Denis Tingaikin (Xored) - **New since last review**
In addition, as the Network Service Mesh has grown, it has recently begun adding sub-MAINTAINERS to specific repos in the organization:
* Alexandre Menezes (Red Hat) - [nsm-operator](https://github.com/networkservicemesh/nsm-operator)
* Denis Tingajkin (Xored) - [fanout](https://github.com/networkservicemesh/fanout)
* Dimitrios Markou (Ericsson Software Technology) - [sdk-ovs](https://github.com/networkservicemesh/sdk-ovs), [cmd-forwarder-ovs](https://github.com/networkservicemesh/cmd-forwarder-ovs) - **New since last review**
* Periyasamy Palanisamy (Ericsson Software Technology) - [sdk-ovs](https://github.com/networkservicemesh/sdk-ovs), [cmd-forwarder-ovs](https://github.com/networkservicemesh/cmd-forwarder-ovs) - **New since last review**
* Laszlo Kiraly (Ericsson Software Technology) - [cmd-nse-remote-vlan](https://github.com/networkservicemesh/cmd-nse-remote-vlan) - **New since last review**
3. _What do you know about adoption, and how has this changed since your last review / since you joined Sandbox? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.)_
At least four companies are beginning to build this into next generation architecture:
* [Anthem](https://anthem.ai/)
* [Ericsson](https://www.ericsson.com/en)
* [Intel](https://www.intel.com/)
* [Cisco](https://www.cisco.com/)
4. _How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)_
Goals from last time:
- *v1.0.0 release.* - Done. The refactor of NSM took longer than expected, but NSM has now settled into a regular 60 day release candence.
- *Continue to expand and broaden the NSM community.* - NSM has increased the breath of maintainers overall, particularly in sub-maintainers for particular repos
- *Grow adoption across: Service Provider* - “Ericsson is actively contributing to NSM to enable 5G specific use cases for cloud native network functions. We have multiple NSM based solutions in our roadmap, targeting live deployments by the end of 2022.”
- *Grow adoption across: Edge/IoT* - "NSM is being considered in the Intel Smart Edge Open roadmap for Service Function Chaining (SFC) of FD.io VPP based Container Network Functions (CNFs)"
- *Grow adoption across: Enterprise* - The NSM vL3 and Application Service Mesh over vL3 (see below) features need to be delivered to enable traction in Enterprise.
5. _What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?_
1. Maintaining a regular (currently 60 day) release candence. Next scheduled release is [NSM v1.3.0](https://networkservicemesh.io/docs/roadmap/v1.3.0/)
2. Build out Enterprise Network Services:
1. vL3 - Virtual L3 - a flat IP networking domain to which workloads from different clusters/clouds/etc can connect and over which they can communicate
2. Application Service Mesh (L7) over vL3 (Note: This goal involves *running* an existing service mesh like Linkerd/Istio/OpenServiceMesh/Kuma over a Network Service Mesh provided vL3. NSM will *not* be writing its own L7 functionality)
6. _How can the CNCF help you achieve your upcoming goals?_
CNCF has been incredibly helpful to Network Service Mesh. All of our requests have been either been met
enthusiastically, or we have been informed cannot be provided until we reach incubation or graduation as a matter of
policy set by the Board and/or TOC.
7. _Do you think that your project meets the [criteria for incubation](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage)?_
Network Service Mesh does not currently meet all criteria for incubation, but is on track to do so.
Network Service Mesh believes that it meets or can trivially meet all criteria for incubation *except* adoption.
There is interest from adopters in 2022, we hope to make progress on adoption this year.
## Project Links
* [Website](https://networkservicemesh.io/)
* [Github](https://github.com/networkservicemesh/)
* [Weekly Meeting Minutes](https://docs.google.com/document/d/1C9NKjo0PWNWypROEO9-Y6haw5h9Xmurvl14SXpciz2Y/edit#heading=h.rc9df0a6n3ng)
* [Twitter](https://twitter.com/nservicemesh)
* [Linkedin](https://www.linkedin.com/company/networkservicemesh)
* [Youtube Channel](https://www.youtube.com/channel/UCXB3ccAbw9qLXSwDNzrkWhA)
* [Network Service Mesh Sandbox Proposal](https://github.com/cncf/toc/pull/212)
* [Network Service Mesh TOC Presentation Slides](https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g54dcbc5536_7_215)

125
reviews/2022-SchemaHero-annual.md Normal file
View File

@ -0,0 +1,125 @@
# Schemahero 2022 Annual Review
This is the Kubernetes TOC Annual Review for the [Schemahero](https://schemahero.io) project for 2022.
## Table of Contents
- [Background](#background)
- [DevStats](#devstats)
- [Maintainers](#maintainers)
- [Adoption](#adoption)
- [Project goals](#project-goals)
- [CNCF Membership](#cncf-membership)
- [Incubation](#incubation)
- [Project Links](#project-links)
## Background
Schemahero is an implementation of declarative database schema management. The goal of the Schemahero project is to simplify management of database schema changes in various environments. Schemahero allows developers to define the desired state of a database schema and the Schemahero project will generate the migration commands needed to migrate an existing database schema to the desired schema.
Declarative change management is the cloud-native way to manage a database schema. Similar to how Kubernetes brings a common API to define the desired state of a cluster, Schemahero implements a common API to define the desired schema of a database.
In addition to schema management, Schemahero aims to implement approval workflows to simplify change management of schemas in organizations that have strict policies or regulatory requirements to manage the database. Schemahero can work with change management tools that integrate with git to provide a policy-driven approach to database schema management.
Schemahero's initial implementation is a Kubernetes operator, making it easy to manage any supported database schema using existing Kubernetes CI/CD tooling, including gitops workflows. This also allows Schemahero manifests to be compatible with many other CNCF projects for policy validation and enforcement, deployment pipelines, change management, and more.
Schemahero was accepted as a CNCF Sandbox project on [October 10th, 2020](https://docs.google.com/spreadsheets/d/1Nnh_usr0tSZxaUpxTusqeIqKxMmvuEViRkyO9e_Do40).
## DevStats
> Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.
The Schemahero DevStats dashboards can be found [here](https://schemahero.devstats.cncf.io/d/8/dashboards?orgId=1&viewPanel=2&from=now-2y&to=now-1h&editPanel=2).
We are using the following metrics from the DevStats metrics as key indicators of community health:
* [Stargazers and Forks](https://schemahero.devstats.cncf.io/d/3/stars-and-forks-by-repository?orgId=1): 265% annual growth from 194 -> 516. Stars are a key way for us to measure awareness of the project.
* [Commits per week](https://schemahero.devstats.cncf.io/d/1/activity-repository-groups?orgId=1&var-period=w&var-repogroups=All&from=now-6M&to=now): Always looking for consistent and then increased activity in the projects
* [Contributors and Companies](https://schemahero.devstats.cncf.io/d/7/companies-contributing-in-repository-groups?orgId=1&var-period=d7&var-repogroup_name=All&from=now-1y&to=now): This has recently started to become a key metric that we want to transition from consistent to increasing. More on this goal below.
## Maintainers
Schemahero currently has 7 maintainers, but currently all are from a single company:
| Maintainer | GitHub Username | Affiliation |
| -------------------- | --------------------------------------------- | ----------- |
| Marc Campbell | [@marccampbell](https://github.com/marccampbell) | Replicated |
| Dmitriy Ivolgin | [@divolgin](https://github.com/divolgin) | Replicated |
| Ethan Mosbaugh | [@emosbaugh](https://github.com/emosbaugh) | Replicated |
| Andrew Lavery | [@laverya](https://github.com/laverya) | Replicated |
| Dan Stough | [@danstough](https://github.com/danstough) | Replicated |
| Salah Aldeen Al Saleh | [@sgalsaleh](https://github.com/sgalsaleh) | Replicated |
| Treva Nichole Williams | [@OGtrilliams](https://github.com/OGtrilliams) | Replicated |
The maintainer list is managed in our [GitHub repository](https://github.com/schemahero/schemahero/blob/main/OWNERS.md). Our [governance policy](https://schemahero.io/community/) is maintained on the project website.
## Adoption
In October 2021, we created an Adopters file to start to track publicly referenceable uses of the projects. Adopters who are publicly referenceable will be listed in the [SchemaHero GitHub repository ADOPTERS file](https://github.com/schemahero/schemahero/blob/main/ADOPTERS).
Schemahero adopters include:
**Projects**
* [KOTS](https://github.com/replicatedhq/kots)
**Organizations**
* [Replicated](https://www.replicated.com/)
**Evaluating Organizations**
* [Tyro](http://www.tyro.com/)
* Several unnamed organizations are evaluating (but not yet selected) Schemahero
## Project Goals
> How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
When we were accepted as a Sandbox project, it was early for Schemahero. Our initial goals were to share the idea and leverage the CNCF platform to get feedback from additional potential users of the project. To do this, we needed to focus on some specific features such as additional database support and functionality such as secrets management (integration with Vault and others) in order to ensure that the Schemahero solution is broad enough to be adopted in various architectures.
To that end, we've released several significant minor versions and have evolved the project from 2 databases with 1 methods of secrets to now supporting 6 databases with 3 secrets management methods. This does allow Schemahero to be compatible with more environments, so we've made significant progress against our previously stated goals.
The following list will show our 4 previous areas of focus with a status update on each:
* **Additional database support**: When joining the sandbox, Schemahero supported Postgres and Mysql. Today we support Postgres, Mysql, Cockroachdb, Yugabyte, Cassandra, SQLite, and are working on TimescaleDB support. We continue to believe that making a single syntax and workflow for all database schema definitions will be a key value of the project and gain more adoption.
* **Additional environment support**: Schemahero has added support for configuration from Hashicorp Vault (via a community contribution) and Amazon Web Services parameter store. In addition, Schemahero has added support for publishing a software bill of materials (SBOM) with each release using sigstore. We are working to "meet the end user where they are" and prioritizing work that decreases the effort needed to adopt a Schemahero POC.
* **Additional use cases**: In addition to schema management, we've identified that Schemahero only solves some of the problems solved by traditional database schema management tools. Until schemahero can replace all of the functionality of traditional solutions, it's difficult to get an organization to convert. We've started working on the primary missing use cases: support for fixtures and seed data, and deploying migrations that need to execute code or other user-defined migration processes (data migrations).
* **Community and Awareness**: This is an opportunity for the project to do better. We've been focusing on building functionality and some maturity to the project, and must start to be more visible in the community to get feedback. In 2021, the project joined the CNCF BugBash, had a desk at the CNCF Project Pavilion (LA), and participated in live office hours during Kubecon. We've also started hosting live and recorded community calls monthly on zoom, and have had community participation in these.
> What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
The current goals of the Schemahero have changed from our original. We currently have three goals:
1. **Integration**: There are other, popular, non-CNCF tools that are popular database schema management projects and products. We've been evaluating integrating these projects and products (OSS and proprietary) into Schemahero so that an organization can adopt Schemahero alongside an existing tool, not just as a replacement for existing tools.
2. **Adoption**: Schemahero is currently being evaluated in several organizations, and our primary goal is to work with these (and future) organizations during the proof of value phase. These early adopters have expressed interest, and are continuing to slowly roll Schemahero into various environments. Feature work (database support and other functionality) will be focused on areas that can increase adoption.
3. **Community**: We aim to continue growing the Schemahero community. Schemahero was an early project when it joined the sandbox, and needed to continue to grow in maturity and find a use case. We will continue to rely on the community for this, and are expecting to spend significant time working with additional committers, maintainers, and end users of the project. We want to have more committers and more maintainers vs more commits.
## CNCF membership
> How can the CNCF help you achieve your upcoming goals?
Schemahero has benefited from inclusion in the CNCF, especially in the areas of awareness and confidence as an early project. Many current evaluations have come from awareness as part of the CNCF. This has also helped to increase confidence (lower risk) for some as the project is still early.
Some areas where we'd like to get continued and additional help are:
* Opportunities to present and discuss Schemahero in order to increase adoptions. This can be webinars, office hours, events, blogs, or other formats.
* Add Schemahero to the Certified Kubernetes Security Specialist (CKS) examination to help build a community of expertise in the project.
* Resources to create case studies that demonstrate the value of Schemahero in both increased velocity and lower risk when managing database schemas.
## Incubation
> Do you think that your project meets the [criteria for incubation](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage)?
Not at this time. It's the goal of the Schemahero project to continue to build in the Sandbox for the next year to increase production-grade adoption and add additional maintaining organizations. Once the project has achieved production status and has moved out of evaluation phases at adopting organizations, we will start planning for incubation.
## Project Links
- [Website](https://schemahero.io)
- [GitHub](https://github.com/schemahero)
- [Slack](https://slack.k8s.io/#schemahero)
- [Twitter](https://twitter.com/schemahero)

101
reviews/2022-cert-manager-annual.md Normal file
View File

@ -0,0 +1,101 @@
# cert-manager 2022 Annual Review
cert-manager provides reliable, automated Kubernetes-native management of X.509 certificates, reducing the risk of certificate-related outages and enabling PKI at scale. The project comprises cert-manager itself - which adds Kubernetes Custom Resource Definitions (CRDs) for certificate-related concepts, and controllers to manage them - along with a selection of subprojects which focus on solving other issues relating to certificate management.
The project has remained a prominent tool in the Cloud Native space since its inclusion in the CNCF sandbox this year, fuelled by wide community adoption and strong ambition to keep on growing and improving in the future. We aim for cert-manager to slot in as a de facto standard part of the Kubernetes production control plane.
We're really excited for our first annual CNCF review and we're looking forward to 2022!
_NB: Statistics referring to the last year mean "the year up to 2021-12-02"_
## DevStats
[cert-manager's DevStats page](https://certmanager.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m&from=now-1y&to=now-1h) shows a steady rate of contributions throughout the last year.
Importantly for the project, we saw at least [45 new first-time-contributors](https://certmanager.devstats.cncf.io/d/52/new-contributors-table?orgId=1&from=now-1y&to=now&var-repogroup_name=cert-manager&viewPanel=1), only counting the main cert-manager repository.
Among those brand new contributors, cert-manager added 3 official [maintainers](https://github.com/jetstack/cert-manager/blob/71de30931fc54eba59853097b1699ffdc4bbc974/OWNERS) and two contributors who took part in Google Summer of Code 2021: [Arsh Sharma](https://summerofcode.withgoogle.com/archive/2021/projects/4983164438577152/) ([RinkiyaKeDad](https://github.com/RinkiyaKeDad)) and [Tim Ramlot](https://summerofcode.withgoogle.com/archive/2021/projects/5686178510012416/) ([inteon](https://github.com/inteon)). In addition, a previous contributor joined the maintainer team.
The source of commits is varied. A large percentage of activity at any given time is usually from the core maintainers, most of whom work at Jetstack. That said, there are regular contributions from a wide [variety of companies](https://certmanager.devstats.cncf.io/d/4/company-statistics-by-repository-group?orgId=1&var-period=d7&var-metric=activity&var-repogroup_name=cert-manager&var-companies=All&from=now-1y&to=now).
In addition, the time taken for a contribution to get merged has largely [remained steady](https://certmanager.devstats.cncf.io/d/16/opened-to-merged?orgId=1&var-period=m&var-repogroup_name=cert-manager&from=now-1y&to=now).
## Maintainers
As mentioned previously, the project has added several new maintainers over the past year.
[Irbe Krumina (irbekrm)](https://github.com/irbekrm), [Ashley Davis (SgtCoDFish)](https://github.com/SgtCoDFish), [Joakim Ahrlin (jahrlin)](https://github.com/jahrlin) and [Maël Valais (maelvls)](https://github.com/maelvls) - all at Jetstack - joined the [maintainers](https://github.com/jetstack/cert-manager/blob/71de30931fc54eba59853097b1699ffdc4bbc974/OWNERS) team, bringing the total number of maintainers to 9 with one maintainer at Apple, seven at Jetstack and one at Thomas More University in Belgium.
## Adoption
cert-manager was widely adopted for use in Kubernetes clusters across many different organisations even before it joined the CNCF as a sandbox project. That adoption has only continued to grow, as evidenced by very regular activity on the [`#cert-manager`](https://kubernetes.slack.com/archives/C4NV3DWUC) channel on Kubernetes slack and the statistics presented above.
For many Kubernetes cluster administrators, cert-manager forms part of the de facto control plane they set up when they create a cluster. This carries across into suggestions or requirements by several major cloud native projects that cert-manager be installed alongside the required Kubernetes API components. Examples include [the Kubernetes Cluster API](https://cluster-api.sigs.k8s.io/developer/guide.html#cert-manager), [Knative](https://knative.dev/development/install/serving/installing-cert-manager/) and [Istio](https://istio.io/latest/docs/ops/integrations/certmanager/).
We don't closely track raw numbers of cert-manager users, either on cert-manager's [Artifact Hub package](https://artifacthub.io/packages/helm/cert-manager/cert-manager), visitors to [cert-manager.io](https://cert-manager.io) or on the cert-manager [quay.io registry](https://quay.io/repository/jetstack/cert-manager-controller).
That said, as an example of scale, the main cert-manager controller container image on quay.io reports roughly 1M-1.5M+ "actions" daily, which indicates widespread use and deployment although image caching and mirroring may make that number an underestimate of true usage. In addition, our best estimates are that the cert-manager website averages around 1.5k unique visitors per day, and that our helm charts see around 1M downloads per day, but these numbers could be out of date and again might well be undercounts.
As another rough indication of usage, the number of stars on the main cert-manager repository continues to increase steadily and linearly, passing the 8,000 star milestone in [early November 2021](https://certmanager.devstats.cncf.io/d/3/stars-and-forks-by-repository?orgId=1).
## Subprojects
cert-manager itself isn't the only project under the cert-manager umbrella; we've also been increasing the quantity and quality of subprojects and adding more open-source tooling to make it easier to manage Cloud Native certificates and identities.
These subprojects include:
- [istio-csr](https://github.com/cert-manager/istio-csr): Enables the use of cert-manager for issuing [Istio](https://istio.io/) certificates
- [approver-policy](https://github.com/cert-manager/approver-policy): Adds the `CertificateRequestPolicy` resource to define policy over whether a given certificate should be signed by cert-manager
- [csi-driver](https://github.com/cert-manager/csi-driver): Kubernetes CSI plugin to facilitate seamlessly requesting and mounting certificate key pairs into pods
- [csi-lib](https://github.com/cert-manager/csi-lib): A generalised library for building CSI drivers that interact with cert-manager's `CertificateRequest` resource
- [trust](https://github.com/cert-manager/trust): cert-manager, but for certificate trust bundles rather than for issuing certificates
Importantly, we also received the donation of the [`aws-privateca-issuer`](https://github.com/cert-manager/aws-privateca-issuer) from AWS this year and incorporated this external issuer into the cert-manager organization. We hope to start a trend of companies in the PKI / certificate issuance space working with us to assemble the best possible collection of these addons for end-users to take advantage of.
## Current Goals
In the short term, a major goal is to complete the migration of the [jetstack/cert-manager](https://github.com/jetstack/cert-manager) repo into the [cert-manager organization](https://github.com/cert-manager/).
After that, the guiding star will be to target CNCF [incubation](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#incubating-stage), since we believe cert-manager to be a strong candidate for incubation.
We also aim to grow our support for new features and tools in the cloud native ecosystem; recent and ongoing examples include the [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) and the Kubernetes [CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) resource. We're always on the lookout for more in this space.
We're also in the process of:
1. Moving all of our build and test infrastructure over to the CNCF GCP organization
2. Preparing for a new cert-manager release in early 2022
3. Planning more work for the year ahead, with a focus on extensibility through neutral and user-friendly APIs.
## How the CNCF Can Help
As mentioned above, we're migrating our infrastructure to the CNCF organization. Our intention is to move one GCP project - `cert-manager-release` - and to create other projects from scratch. The migration process for the `cert-manager-release` project has been quite slow with a lot of bumps in the road; we'd really like to get that done soon.
Any other assistance would be great; given that cert-manager is so tightly tied to security, the incubation-level security audit would obviously be invaluable. In addition, marketing and project management support is always useful.
As a specific project management example, some aspects of running and maintaining an open source project mirror the joiners / movers / leavers (JML) process which many businesses have in place for onboarding and
offboarding staff members. cert-manager is starting to discover some pain points with these processes internally. For example, when a new maintainer is onboarded, how should we manage cloud access credentials for that
user in a secure and scalable way? These feel like the kinds of problem that might be common to other projects, and any advice or open-source tooling for managing these kinds of JML processes within the project would
be tremendously useful.
Put more generally, we ideally don't want to reinvent the wheel when it comes to project management or "open source JML" and we're sure that there's prior art in this space.
## Incubation
Based on the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#incubating-stage), cert-manager seems to already tick the relevant boxes required for incubation. We believe cert-manager to be a strong candidate for incubation based on the following:
- Document that it is being used successfully in production by at least three independent end users
cert-manager is used in production by _many_ more than three independent end users; it shouldn't be hard to find a few case studies if needed. Several major cloud native projects including [Istio](https://istio.io/latest/docs/ops/integrations/certmanager/), the [Kubernetes Cluster API](https://cluster-api.sigs.k8s.io/developer/guide.html#cert-manager) and [Knative](https://knative.dev/development/install/serving/installing-cert-manager/) suggest or require that cert-manager be installed.
- Have a healthy number of committers
cert-manager has 9 regular maintainers across 3 organisations. Community contributions from many different organizations are very common and gladly received.
- Demonstrate a substantial ongoing flow of commits and merged contributions
Evidence of this can be seen under DevStats above.
- A clear versioning scheme
cert-manager has had a clear versioning scheme and a regular release cadence for many months now. Details can be seen on the [cert-manager website](https://cert-manager.io/docs/installation/supported-releases/) under our "Supported Releases" page.
- Clearly documented security processes explaining how to report security issues
This was added in the past year, with a clear [security process](https://github.com/jetstack/cert-manager/blob/3191293cb8b475f94aa9f4c843178039c5bb6a48/SECURITY.md) and a dedicated email address (`cert-manager-security@googlegroups.com`).
If there are any concerns about cert-manager's eligibility for incubation we'd be more than happy to address them; we're hoping that this annual review will be the first step on the road towards incubation.

265
reviews/incubation-in-toto.md Normal file
View File

@ -0,0 +1,265 @@
# in-toto Incubating Stage Review
in-toto is currently a CNCF sandbox project. Please refer to in-toto's initial
[sandbox proposal](../proposals/sandbox/in-toto.adoc) for discussion on in-toto's
alignment with the CNCF and details on sandbox requirements.
In the time since being accepted as a sandbox project, in-toto has demonstrated
healthy growth and progress. The [Python reference implementation](https://github.com/in-toto/in-toto) has had several releases.
* [v1.1.1 is the latest patch release](https://github.com/in-toto/in-toto/releases),
shipped on Juky 27th, 2021. It added:
* Tests that use source and destination prefixes in match rules, courtesy
of Brandon Michael Hunter ([#456](https://github.com/in-toto/in-toto/pull/456))
Other changes include:
* Updated documentation of command alignment during verification workflow
([#455](https://github.com/in-toto/in-toto/pull/455))
* Started using GitHub-native dependabot
([#450](https://github.com/in-toto/in-toto/pull/450))
* Bump dependencies: attrs ([#451](https://github.com/in-toto/in-toto/pull/451)),
six ([#452](https://github.com/in-toto/in-toto/pull/452)),
securesystemslib ([#453](https://github.com/in-toto/in-toto/pull/453)),
cffi ([#457](https://github.com/in-toto/in-toto/pull/457)),
python-dateutil ([#458](https://github.com/in-toto/in-toto/pull/458)),
iso8601 ([#459](https://github.com/in-toto/in-toto/pull/459)),
pathspec ([#460](https://github.com/in-toto/in-toto/pull/460))
* Fixed linter warnings ([#462](https://github.com/in-toto/in-toto/pull/462))
* [v1.1.0 is the latest minor release](https://github.com/in-toto/in-toto/releases),
shipped on April 30th, 2021. It added:
* SPDX License identifiers and copyright information ([#440](https://github.com/in-toto/in-toto/pull/440))
* Aditya Sirish (@adityasaky) as a maintainer ([#443](https://github.com/in-toto/in-toto/pull/443))
Other changes include:
* PyPI development status from `Beta` to `Production/Stable` ([#447](https://github.com/in-toto/in-toto/pull/447))
* Santiago Torres-Arias's (@SantiagoTorres) email to reflect Purdue affiliation ([#446](https://github.com/in-toto/in-toto/pull/446))
* Debian downstream release metadata ([#437](https://github.com/in-toto/in-toto/pull/437))
* Bump dependency: cryptography ([#442](https://github.com/in-toto/in-toto/pull/442))
Finally, this release removed:
* Support for Python 2.7 ([#438](https://github.com/in-toto/in-toto/pull/438))
* [v1.0.1](https://github.com/in-toto/in-toto/releases),
shipped on March 1st, 2021. This was the final in-toto release that supported Python
2.7. This release added:
* Python 3.9 in the CI test matrix ([#419](https://github.com/in-toto/in-toto/pull/419))
* Logo and other visual enhancements on readthedocs ([#420](https://github.com/in-toto/in-toto/pull/420), [#428](https://github.com/in-toto/in-toto/pull/428))
* Review of first evaluation period for 2021 roadmap ([#421](https://github.com/in-toto/in-toto/pull/421))
The changes include:
* Switch to GitHub Actions for CI ([#432](https://github.com/in-toto/in-toto/pull/432))
* Switch to only running bandit on Python versions greater than 3.5 ([#416](https://github.com/in-toto/in-toto/pull/416))
* Debian downstream release metadata ([#418](https://github.com/in-toto/in-toto/pull/418))
* Bump tested dependencies: cffi ([#415](https://github.com/in-toto/in-toto/pull/415), [#427](https://github.com/in-toto/in-toto/pull/427)), cryptography ([#424](https://github.com/in-toto/in-toto/pull/424), [#429](https://github.com/in-toto/in-toto/pull/429)), securesystemslib ([#430](https://github.com/in-toto/in-toto/pull/430), [#431](https://github.com/in-toto/in-toto/pull/431)), iso8601 ([#423](https://github.com/in-toto/in-toto/pull/423))
* NOTE: the latest version of cryptography is no longer used on Python 2, as that is not supported.
This release removed:
* Dropped support for Python 3.5 ([#419](https://github.com/in-toto/in-toto/pull/419))
* [v1.0.0 is the latest major release](https://github.com/in-toto/in-toto/releases),
shipped on November 23rd, 2020. This release added:
* '-P/--password' (prompt) cli argument for in-toto-run/in-toto-record ([#402](https://github.com/in-toto/in-toto/pull/402))
* in-toto-run link command timeout setting ([#367](https://github.com/in-toto/in-toto/pull/367))
* API and usage documentation for cryptographic key handling with securesystemslib ([#402](https://github.com/in-toto/in-toto/pull/402), [#408](https://github.com/in-toto/in-toto/pull/408))
* Artifact recording exclude pattern documentation ([#373](https://github.com/in-toto/in-toto/pull/373), [#405](https://github.com/in-toto/in-toto/pull/405))
* Test key generation mixin ([#402](https://github.com/in-toto/in-toto/pull/402))
* 2021 roadmap document ([#381](https://github.com/in-toto/in-toto/pull/381))
The changes include:
* Move 'settings' docs to new 'configuration' section and make minor enhancements in structure and content ([#405](https://github.com/in-toto/in-toto/pull/405))
* Update tested dependencies ([#377](https://github.com/in-toto/in-toto/pull/377), [#383](https://github.com/in-toto/in-toto/pull/383), [#384](https://github.com/in-toto/in-toto/pull/384), [#386](https://github.com/in-toto/in-toto/pull/386), [#389](https://github.com/in-toto/in-toto/pull/389), [#390](https://github.com/in-toto/in-toto/pull/390), [#394](https://github.com/in-toto/in-toto/pull/394), [#397](https://github.com/in-toto/in-toto/pull/397), [#398](https://github.com/in-toto/in-toto/pull/398), [#400](https://github.com/in-toto/in-toto/pull/400), [#404](https://github.com/in-toto/in-toto/pull/404), [#406](https://github.com/in-toto/in-toto/pull/406), [#409](https://github.com/in-toto/in-toto/pull/409), [#410](https://github.com/in-toto/in-toto/pull/410), [#411](https://github.com/in-toto/in-toto/pull/411))
* Debian downstream release metadata ([#382](https://github.com/in-toto/in-toto/pull/382))
This release removed:
* 'util' crypto module in favor of securesystemslib key interfaces ([#402](https://github.com/in-toto/in-toto/pull/402))
* Obsolete coveralls.io API call in Travis test builds ([#399](https://github.com/in-toto/in-toto/pull/399))
And it fixed:
* Minor docs issues ([#396](https://github.com/in-toto/in-toto/pull/396), [#385](https://github.com/in-toto/in-toto/pull/385), [#395](https://github.com/in-toto/in-toto/pull/395))
* pylint 2.6.0 ([#387](https://github.com/in-toto/in-toto/pull/387)) and lgtm.com ([#379](https://github.com/in-toto/in-toto/pull/379)) warnings
* [v0.5.0](https://github.com/in-toto/in-toto/releases),
shipped on July 13th, 2020. New features include:
* Docs: Major CLI and API documentation overhaul and release ([#341](https://github.com/in-toto/in-toto/pull/341), [#369](https://github.com/in-toto/in-toto/pull/369))
* Bugfix: Use kwargs in in-toto-run to fix lstrip-paths bug ([#340](https://github.com/in-toto/in-toto/pull/340))
* Feature: Add option to specify target directory for generated metadata ([#364](https://github.com/in-toto/in-toto/pull/364))
* Tests: Add Python 3.8 to tested versions ([#339](https://github.com/in-toto/in-toto/pull/339))
* Tests: Add tmp dir and gpg key test mixins ([#345](https://github.com/in-toto/in-toto/pull/345))
* Tests: Use constant from securesystemslib to detect GPG in tests ([#352](https://github.com/in-toto/in-toto/pull/352))
* Tests: Enhance test suite feedback on Windows ([#368](https://github.com/in-toto/in-toto/pull/368))
* Dependencies: Misc updates ([#342](https://github.com/in-toto/in-toto/pull/342), [#346](https://github.com/in-toto/in-toto/pull/346), [#349](https://github.com/in-toto/in-toto/pull/349), [#350](https://github.com/in-toto/in-toto/pull/350), [#353](https://github.com/in-toto/in-toto/pull/353), [#354](https://github.com/in-toto/in-toto/pull/354), [#356](https://github.com/in-toto/in-toto/pull/356), [#358](https://github.com/in-toto/in-toto/pull/358), [#359](https://github.com/in-toto/in-toto/pull/359), [#362](https://github.com/in-toto/in-toto/pull/362), [#363](https://github.com/in-toto/in-toto/pull/363), [#366](https://github.com/in-toto/in-toto/pull/366))
* [v0.4.2](https://github.com/in-toto/in-toto/releases),
shipped on January 7th, 2020. New features include:
* Drop custom OpenPGP subpackage and subprocess module and instead use the ones provided by securesystemslib, which are based on the in-toto implementation and receive continued support from a larger community ([#325](https://github.com/in-toto/in-toto/pull/325))
* Fix a race condition that caused tests to sporadically fail was already fixed in securesystemslib and is now also available to in-toto ([#282](https://github.com/in-toto/in-toto/pull/282), [secure-systems-lab/securesystemslib#186](https://github.com/secure-systems-lab/securesystemslib/pull/186))
* Add Sphinx boilerplate and update installation instructions ([#298](https://github.com/in-toto/in-toto/pull/298), [#331](https://github.com/in-toto/in-toto/pull/331))
* Update misc dependencies ([#317](https://github.com/in-toto/in-toto/pull/317), [#318](https://github.com/in-toto/in-toto/pull/318), [#319](https://github.com/in-toto/in-toto/pull/319), [#320](https://github.com/in-toto/in-toto/pull/320), [#322](https://github.com/in-toto/in-toto/pull/322), [#323](https://github.com/in-toto/in-toto/pull/323), [#324](https://github.com/in-toto/in-toto/pull/324), [#326](https://github.com/in-toto/in-toto/pull/326), [#327](https://github.com/in-toto/in-toto/pull/327), [#328](https://github.com/in-toto/in-toto/pull/328), [#333](https://github.com/in-toto/in-toto/pull/333), [#335](https://github.com/in-toto/in-toto/pull/335), [#329](https://github.com/in-toto/in-toto/pull/329))
* Update downstream debian metadata ([#311](https://github.com/in-toto/in-toto/pull/311), [#334](https://github.com/in-toto/in-toto/pull/334))
* [v0.4.1](https://github.com/in-toto/in-toto/releases),
was shipped on Oct 14th, 2019. New features include:
* Update securesystemslib dependency to v0.12.0 ([#299](https://github.com/in-toto/in-toto/pull/299))
* Add --version option to CLI tools ([#310](https://github.com/in-toto/in-toto/pull/310))
* Address linter warnings ([#308](https://github.com/in-toto/in-toto/pull/308))
* Update downstream debian metadata ([#302](https://github.com/in-toto/in-toto/pull/302), [#305](https://github.com/in-toto/in-toto/pull/305), [#309](https://github.com/in-toto/in-toto/pull/309))
* [v0.4.0](https://github.com/in-toto/in-toto/releases),
shipped on September 9th, 2019. New features include:
* Full artifact rule spec compliance ([#269](https://github.com/in-toto/in-toto/pull/269), [#280](https://github.com/in-toto/in-toto/pull/280))
* Enhanced OpenPGP key export and key expiration verification ([#266](https://github.com/in-toto/in-toto/pull/266), [#288](https://github.com/in-toto/in-toto/pull/288))
* Transitive PyNaCl dependency is now optional ([#291](https://github.com/in-toto/in-toto/pull/291))
* Improved automatic test coverage analysis ([#295](https://github.com/in-toto/in-toto/pull/295))
* Static analysis improvements ([279](https://github.com/in-toto/in-toto/pull/279), [#296](https://github.com/in-toto/in-toto/pull/296))
* Improve upstream release packaging for Debian and Arch Linux ([#279](https://github.com/in-toto/in-toto/pull/279), [#290](https://github.com/in-toto/in-toto/pull/290))
More changes and small improvements are mentioned in the current release
changelog.
Further, the [Go implementation](https://github.com/in-toto/in-toto-golang) has had several
pre-releases, the latest being [v0.3.2](https://github.com/in-toto/in-toto-golang/releases).
In recent months, the Go implementation has emerged as the bleeding-edge implementation, with
support for newer experimental features such as those of proposed enhancements to
the in-toto specification. One recent example is the addition of PKI support to the Go implementation.
There are also in-toto implementations written in [Rust](https://github.com/in-toto/in-toto-rs)
and [Java](https://github.com/in-toto/in-toto-java). The former was largely developed by a
student contributor during Google Summer of Code 2021, and the latter is now being reworked
to incorporate newer changes to in-toto, such as the switch to a new signature envelope.
Beyond the current release other improvements to the broader reference
implementation have been achieved.
A [formalized governance policy](https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md)
has been instituted project-wide. This includes not only the in-toto python
reference implementation, but the specifications, implementations in other
languages and cloud-native tooling.
## Incubating Stage Criteria
In addition to sandbox requirements, a project must meet the following
criteria to become an incubation-stage project:
### Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgment, are of adequate quality and scope
* In general, we document adopters on
[our website](https://in-toto.io/integrations.html).
* Datadog uses a combination of in-toto and TUF to securely distribute their
agent integrations. They have described this in detail
[here](https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/).
* The in-toto specification has inspired
the development of [Argos Notary](https://www.argosnotary.com/docs/00_overview/10_overview)
by Rabobank.
* Boxboat is integrating SPIFFE, another CNCF project, with in-toto. This
integration is documented in [ITE-7](https://github.com/in-toto/ITE/pull/21).
* in-toto is also used by Cloud Native Application Bundles (CNAB), another
CNCF project, in [Signy](https://github.com/cnabio/signy).
* [rebuilderd](https://github.com/kpcyrd/rebuilderd) can generate in-toto
metadata. This project is an orchestrator for rebuilders part of the
Reproducible Builds project. Some examples of in-toto links in the wild:
[wolfpit.net/rebuild](https://wolfpit.net/rebuild/api/v0/builds/26738/attestation)
[r-b.engineering.nyu.edu](https://r-b.engineering.nyu.edu/api/v0/builds/55502/attestation)
* In the current implementations and demonstrations, the
[in-toto Attestation](https://github.com/in-toto/attestation) project is
the metadata vehicle of choice for
[SLSA requirements](https://slsa.dev/requirements#provenance-requirements).
* [Tekton Chains](https://github.com/tektoncd/chains) is another example of
in-toto integration. Chains can generate in-toto metadata, capturing
information from the pipeline.
* The [Sigstore](https://www.sigstore.dev/) project also supports in-toto
metadata, though a tighter integration is under active development. Google
mentioned this interaction in this
[blog post](https://security.googleblog.com/2021/06/verifiable-supply-chain-metadata-for.html).
* The [Qubes OS](https://www.qubes-os.org/) project uses in-toto with our
apt-transport within [their reproducible builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/)
setup.
* IBM is working on a [proof-of-concept](https://github.com/IBM/argocd-interlace)
that combines in-toto and ArgoCD.
### Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project
* Maintainers of the project are listed in our
[MAINTAINERS.txt](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt)
file. There are currently five core maintainers from Purdue University, New
York University, and Conda who cut releases.
* Several other people have commit access, but cannot craft releases. They are:
* Holger Levsen (Debian)
* Holger helps us with packaging in-toto and the apt-transport for Debian
* Ofek Lev (Datadog)
* Ofek helps us maintain the git-specific semantics with in-toto
* We have had contributions from people associated with different organizations.
Some of them, listed in no particular order:
* Trishank Karthik Kuppusamy (Datadog)
* Joshua Lock (VMWare)
* Dan Lorenc (Google)
* Fredrik Skogman (Solar Winds)
* Christian Rebischke (Arch Linux)
* Maintainers are added and removed from the project as per the policies
outlined in the project [GOVERNANCE.md](https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md)
file.
* Finally, in-toto participated in Google Summer of Code (GSOC) in
[2020](https://www.cncf.io/blog/2020/10/07/gsoc-spotlight-my-google-summer-of-code-experience-at-cncf-in-2020/) and
[2021](https://coda.io/@joy/2021-gsoc-story) through the CNCF.
### Demonstrate a substantial ongoing flow of commits and merged contributions
* Releases: There were eight [releases](https://github.com/in-toto/in-toto/releases)
scheduled since the sandbox application as defined on our
[release schedule](https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md).
* Roadmap: We have annual roadmaps for
[the reference implementation](https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md)
and [in-toto as a whole](https://github.com/in-toto/docs/blob/master/ROADMAP.md).
Reviews are released at the end of each evaluation period described in the
roadmap, and they can be found in the repositories for the
[reference implementation](https://github.com/in-toto/in-toto/tree/develop/roadmap-reviews)
and [in-toto docs](https://github.com/in-toto/docs/tree/master/roadmap-reviews).
* in-toto Enhancements (ITEs): We have a [formal process](https://github.com/in-toto/ITE)
for interested parties to submit new features or describe some aspect or
integration of the in-toto specification. Since in-toto was accepted into
the CNCF sandbox, the following ITEs have been proposed:
* [ITE-2](https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc) by Trishank Karthik Kuppusamy (Datadog), "Draft"
* [ITE-3](https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc) by Trishank Karthik Kuppusamy (Datadog), "Accepted"
* [ITE-4](https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc) by Santiago Torres-Arias (Purdue University), "Accepted"
* [ITE-5](https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc) by Santiago Torres-Arias (Purdue University), "Accepted"
* [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6) by Mark Lodato (Google), "Draft"
* [ITE-7](https://github.com/in-toto/ITE/pull/21) by Mikhail Swift (Boxboat), discussions ongoing
* [ITE-8](https://github.com/in-toto/ITE/pull/29) by Furkan Turkal, Erkan Zileti, Batuhan Apaydin, discussions ongoing
* Contributors: [https://github.com/in-toto/in-toto/graphs/contributors](https://github.com/in-toto/in-toto/graphs/contributors)
* Commit activity: [https://github.com/in-toto/in-toto/graphs/commit-activity](https://github.com/in-toto/in-toto/graphs/commit-activity)
* CNCF DevStats: [https://intoto.devstats.cncf.io/](https://intoto.devstats.cncf.io/)
* [Last 30 days activity on GitHub](https://intoto.devstats.cncf.io/d/8/dashboards?refresh=15m&orgId=1&from=now-30d&to=now-1h)
* [Community Stats in-toto-python](https://intoto.devstats.cncf.io/d/3/stars-and-forks-by-repository?orgId=1&var-period=d7&var-repo_name=in-toto%2Fin-toto)
* [Community Stats in-toto-golang](https://intoto.devstats.cncf.io/d/3/stars-and-forks-by-repository?orgId=1&var-period=d7&var-repo_name=in-toto%2Fin-toto-golang)
## Security
Given that in-toto is a security product, in-toto's codebase has been written,
designed and tested with security in mind. Some of the actions performed in
order to ensure the quality and security of the codebase, as well as in-toto's
design and specification include:
* Static analysis is performed using [pylint](https://github.com/PyCQA/pylint/) and [bandit](https://bandit.readthedocs.io/en/latest/)
* Dependency vulnerability tracking using [Dependabot](https://dependabot.com/)
* Manual code analysis / review by a Maintainer for each included piece of
code
* [Security assessment](https://github.com/cncf/sig-security/blob/master/assessments/projects/in-toto/self-assessment.md) by CNCF's SIG-SECURITY
* A peer-reviewed paper describing the threat model, its
security properties, was published in
[USENIX Security '19](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias)
* in-toto's implementation has received the [CII Silver Criteria Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523)
for best development practices
A more elaborated description of these security initiatives, as well as a
vulnerability report process is included [here](https://github.com/in-toto/in-toto#security-issues-and-bugs).

23
tags/README.md
View File

@ -15,15 +15,15 @@ a pull request with document referencing the roles and charter, updating the lis
| Name | TOC Liaisons |
|------|--------------|
| [TAG Security](https://github.com/cncf/tag-security) | Liz Rice, Justin Cormack |
| [TAG Storage](https://github.com/cncf/tag-storage) | Erin Boyd, Saad Ali |
| [TAG App Delivery](https://github.com/cncf/tag-app-delivery) | Davanum Srinivas, Lei Zhang, Cornelia Davis |
| [TAG Network](https://github.com/cncf/tag-network) | Dave Zolotusky, Liz Rice |
| [TAG Runtime](https://github.com/cncf/tag-runtime) | Richardo Rocha, Alena Prokharchyk, Davanum Srinivas |
| [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) | Saad Ali, Alena Prokharchyk |
| [TAG Observability](https://github.com/cncf/tag-observability) | Lei Zhang, Cornelia Davis |
| [TAG Security](https://github.com/cncf/tag-security) | Emily Fox, Justin Cormack |
| [TAG Storage](https://github.com/cncf/tag-storage) | Erin Boyd, Richard Hartmann |
| [TAG App Delivery](https://github.com/cncf/tag-app-delivery) | Matt Farina, Lei Zhang, Cornelia Davis |
| [TAG Network](https://github.com/cncf/tag-network) | Dave Zolotusky, Davanum Srinivas |
| [TAG Runtime](https://github.com/cncf/tag-runtime) | Richardo Rocha, Richard Hartmann, Davanum Srinivas |
| [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) | Matt Farina, Katie Gamanji |
| [TAG Observability](https://github.com/cncf/tag-observability) | Lei Zhang, Cornelia Davis |
## TAG Chairs as of February 2022
## TAG Chairs as of March 2022
### TAG Storage
* [Xing Yang](https://github.com/xing-yang)
@ -33,11 +33,12 @@ a pull request with document referencing the roles and charter, updating the lis
### TAG Security
* [Brandon Lum](https://github.com/lumjjb)
* [Aradhna Chetal](https://github.com/achetal01)
* [Andrew Martin](https://github.com/sublimino)
### TAG App-Delivery
* [Bryan Liles](https://github.com/bryanl)
* [Lei Zhang](https://github.com/resouer)
* [Alois Reitbauer](https://github.com/AloisReitbauer)
* [Jennifer Strejevitch](https://github.com/Jenniferstrej)
* [Hongchao Deng](https://github.com/hongchaodeng)
### TAG Network
* [Lee Calcote](https://github.com/leecalcote)
@ -63,6 +64,8 @@ a pull request with document referencing the roles and charter, updating the lis
| TAG | Emeritus Chair |
|---|---|
| TAG App Delivery | [Bryan Liles](https://github.com/bryanl) |
| TAG App Delivery | [Lei Zhang](https://github.com/resouer) |
| TAG Contributor Strategy | [Gerred Dillon](https://github.com/gerred) |
| TAG Security | [Sarah Allen](https://github.com/ultrasaurus) |
| TAG Security | [Jeyappragash Jeyakeerthi](https://github.com/pragashj) |

2
tags/security.md
View File

@ -10,7 +10,7 @@ final review by Liz Rice, Joe Beda and Zhipeng Huang.
**TOC Liaisons:** [Justin Cormack](https://github.com/justincormack)
**TAG Chairs:** [Brandon Lum](https://github.com/lumjjb), [Aradhana Chetal](https://github.com/achetal01)
**TAG Chairs:** [Brandon Lum](https://github.com/lumjjb), [Aradhana Chetal](https://github.com/achetal01), [Andrew Martin](https://github.com/sublimino)
**Tech Leads:**
* Justin Cappos ([@JustinCappos](https://github.com/JustinCappos)), New York University