From 0ddb0dabae75783dac29d77576717a79c676adf2 Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Sun, 17 Sep 2017 22:38:51 -0400 Subject: [PATCH 01/27] Added draft of TOC principles document Signed-off-by: Dan Kohn --- principles.md | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 principles.md diff --git a/principles.md b/principles.md new file mode 100644 index 0000000..3852641 --- /dev/null +++ b/principles.md @@ -0,0 +1,149 @@ +# CNCF TOC Goals and Principles +​ +_Version 0.9, September 17, 2017 +Approved by TOC on: TBD +Approved by GB on: TBD_ +​ +[TOC Operating Principles](#toc-operating-principles) +[We Are Project-Centric](#we-are-project-centric) +[Projects Are Self-Governing](#projects-are-self-governing) +[What We're Looking For](#what-were-looking-for) +[No Kingmakers & One Size Does Not Fit All](#no-kingmakers--one-size-does-not-fit-all) +[Not a Standards Body](#not-a-standards-body) +[We Want a Comprehensive Toolchain](#we-want-a-comprehensive-toolchain) +[Above All We Want To Help Projects](#above-all-we-want-to-help-projects) +​ +## TOC Operating Principles +​ +Now that CNCF has been active for over a year we want to start writing down what we have learned. Future TOCs can still make changes, but there will at least be documented precedent. +​ +### We Are Project-Centric +​ +_Principle: If it can be on a modern public source code control system, then it can be a project. And we put projects front and center._ +​ +CNCF is a home for several kinds of “project” where community collaboration furthers the goals of the CNCF community: +1. Open source software projects, e.g., Prometheus. +1. Projects that develop interface and/or schema specifications (e.g., [CNI](https://github.com/containernetworking/cni), reference implementations, conformance tests, adaptors, etc., in order to facilitate interoperability. +1. Reference materials, such as architectures, stacks, guides, docs. + +## Projects Are Self-Governing +​ +_Principle: Minimal Viable Governance_ +​ +Our expectations around governance and support are all predicated on the notion that a CNCF project works like a typical, modern “community-owned” open source software project, such as a person might discover hosted on GitHub. That means that it has ‘committers’ and shared ownership using source code control, etc. People who want the CNCF to support their ‘thing’ need to make it into a project and support “GitHub-style” communities. (Though please note that CNCF projects don't actually need to live on GitHub.) +​ +In the GitHub era, open projects are able to get a lot “done” without outside help. The CNCF does not want to get in the way of that. This starts with “minimal viable governance”. +​ +- The CNCF, TOC, and GB are available for help if it is asked for. +- But: we do not want to impose bureaucracy on projects because that will slow them down. +- Minimal viable governance also means that the TOC does not step in at a tactical level to overrule project leads’ decisions. +- There are some basics like [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) - see Draft Statement below. Including dealing with problematic leads & maintainers. +- There is a formal & regulated system of [Graduation Criteria](https://www.cncf.io/projects/graduation-criteria/) for CNCF Projects +- The TOC/CNCF want the ability to intervene if things go really wrong - i.e., project leads are stuck and cannot fix things. +- Provide a template for new projects, a set of best practices to help jump-start the task of setting up a new project. +​ +### Draft Public Statement for website +​ +The CNCF is committed to helping its member projects succeed, but without dictating or micromanaging how the projects are run. To that end, it requires only minimal viable governance criteria: a [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) with neutral processes for resolving conflicts, a documented governance model that includes a contribution-based process by which contributors can become committers or maintainers, and a clear definition of the top-level project leadership, with which the foundation will engage and inform and from which it may receive requests for funding and support. Once a project has graduated from incubation, new governance requirements cannot be imposed without consent of the project, except where legally required. +​ +## What We're Looking For +​ +We are looking for high-quality, high-velocity projects that fit ‘cloud native’. +​ +_Principle: Great projects already have many ingredients to succeed. First: do no harm._ +​ +Identify projects that have a real shot at being a useful tool in the evolving box of cloud native technology. This is a mix of mature and early-stage projects. Early stage may not have all the criteria we want: diverse contributor bases, formalized governance, interoperability, cloud-native designs, quality bar, etc. +​ +Some considerations: +- Transparent, consistent technical and governance quality bar for [graduation](https://www.cncf.io/projects/graduation-criteria/) from incubation +- Has users, preferably in production; is a high quality, high-velocity project +- Has a committed and excited team that appears to understand the challenges ahead and wishes to meet them +- Has a fundamentally sound design without obvious critical compromises that will inhibit potential widespread adoption +- Is useful for cloud native deployments & ideally, is architected in a cloud native style +- Has an affinity for how CNCF wants to operate +- Charter Section 9(e): _New open source projects initiated in CNCF shall complete a project proposal template adopted by the TOC and be approved by the TOC for inclusion in CNCF. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project, the governance proposed for the project and identify alignment with CNCF’s role and values_ +​ +## No Kingmakers & One Size Does Not Fit All +​ +_Preamble:_ +1. Many problems in technology have more than one solution. Markets are good at finding them. There may be multiple good OSS projects for solving a problem that are optimized for different edge cases. +1. Often multiple solutions get widespread use, for example, because they are optimized for different constraints. We don’t want to get in the way of that by insisting that one technology is “the answer” for each functional gap that we can identify today. We believe that the market and user community provide a good mechanism for pushing the most appropriate projects forward over time. We want projects to enjoy the support of the CNCF during that process. +1. There is no “one true stack”, cloud native applications cover many different use cases with different needs. Many architectures are reasonable: from 12-factor to microservice, to stateful or data-intensive, to others. And there are many scales from one node to many, from low to high latency, etc. So “one size does not fit all”. +​ +_Principles:_ +1. No kingmakers. The TOC picks projects with a real chance of achieving widespread use, and it does not pick a winner in each category. Similar or competitive projects are not excluded for reasons of overlap. +1. No one stack. The TOC does not pick a “winning stack” - i.e., vertically integrated set of projects as a solution for multiple application problems. Instead by encouraging interop, we hope that a range of patterns & “stacks” will emerge. +​ +Via the “no kingmakers” principle and “what is a project”, the CNCF may support several projects which show how a ‘stack’ is a solution to certain use cases. For example, some stacks might use a container orchestrator. Other stacks might show how to integrate monitoring with other “observability” technologies, for cloud native apps regardless of their orchestration model. +​ +This means that the CNCF is not promoting a single, monolithic stack of technologies. +​ +The CNCF is a badge of quality and velocity. CNCF projects should be on a path to being tools that users can trust, broadly work together, and that meet other cloud native criteria. But the CNCF badge does not mean “this is the standard tool”. +​ +- Overlapping projects are ok, especially where they make significantly different design tradeoffs +- Who to pick: The market is too young for us to pick winners - sometimes we shall identify several really promising tools that overlap in function. Let's aim for eventual consistency based on real community use, and not create early deadlocks over "which one tool is best". +- CNCF resources, both time and money, to be extremely limited, so we do need to choose carefully, and therefore should do some reasonable due diligence, including considering alternative projects. +- Overall the TOC will try to maintain a public roadmap or “backlog” where it sees interesting projects emerging, or space for “RFPs”, and “WGs”. While not a hard and fast document, this will help make dialogue with the community more transparent & efficient. +​ +## Not a Standards Body +​ +_Principle: CNCF promotes interoperability via interfaces that get real-world use_ +​ +Users and vendors both want as little friction as possible when it comes to integration. Taking any two projects and putting them into a larger stack, product, platform, solution, etc., is always easier when this is the case. For example, cloud native storage vendors want as few moving parts as possible when it comes to making their products and services work with the various emerging container platforms. At the same time, the world is littered with the untouchable remains of failed ‘standards’ that promised to provide interoperability but did not get traction. +​ +In the CNCF we like projects that are getting traction and may go on to become widespread and popular with end users and the ecosystem. We apply this thinking to the area normally covered by ‘standards’ including specifications for APIs, SPIs, protocols, etc. Where a good interface exists we are happy to use it if our users like it, but we are not compelled to do so. +​ +We want markets and users to drive interop, not committees. We want to help real-world use happen faster, and foster collaboration. We do not wish to become gated on committees. +​ +We should focus on areas of rough 'de facto' agreement, under the proviso that early markets are also diverse. Possible areas to target: +- CNI - network +- CSI - storage +- CRI - runtime +- Openmetrics +- CLI - logging +- Spiffe +- (there is demand for some kind of serverless-related event scheme) +​ +### How CNCF works with interface definitions like CNI, vs. standards efforts like OCI +​ +The world has a number of recognized international standards bodies such as IETF and W3C. CNCF is not playing the role of a standards body. By contrast, OCI is a standards body. +​ +CNCF may develop written materials in the style of the current CNI interface document, or in the style of an IETF RFC for example. These CNCF “specification” materials are not “standards”. It is in future possible that an independent and recognized international standards body takes a CNCF document as “upstream” and evolves it into a standard via (e.g.) the IETF process. The CNCF is morally supportive of independent parties doing this, but does not see this work as its own responsibility. For that matter, to date, no such exercise is in process. +​ +In general CNCF specifications will evolve as “living documents” side by side with the CNCF OSS projects that adopt them. This means they are “dynamic and fast-moving” whereas a typical IETF standard is ”static” and not subject to frequent updates & new releases. +​ +For the avoidance of doubt: Any written “specification” materials in CNCF shall have the same status as CNCF open source software and project technical docs. That is to say that specifications shall be updated and release versioned according to the conventions of a CNCF open source project. +​ +### Important: Principle of Interoperability +​ +CNCF values this highly: that for any given ‘specification’, multiple implementations exist. Those implementations will use the project’s specification as the source of truth. +​ +Moreover, CNCF shall not claim interoperability if there is only one implementation. +​ +### Example: CNI +​ +CNI fits all of the above requirements. There is 1) a specification and it is co-developed with 2) a library (libcni) and 3) ecosystem-contributed plugins. Collectively (1-3) form “the CNI Project”. In the future, CNI might include a compliance test suite which can be run against those implementations. +​ +CNI is a software project, but the centerpiece of that project is the set of interfaces documented in the specification. Those interfaces live in the CNI Project. By the principle of interoperability, the existence of multiple CNI implementations is encouraged. Those implementations will use the interface definition from CNI as the source of truth. +​ +### Example: OCI +​ +OCI is not in the CNCF. The OCI project operates according to the norms of international standards bodies and has a clear primary goal: to provide a document that describes a standard set of interfaces for a container runtime and label this as 1.0. Nothing else is required. +​ +## We Want a Comprehensive Toolchain +​ +_Principle: users don’t need to look beyond the CNCF for cloud native app tooling_ +​ +Grand vision: CNCF should identify, facilitate and promote a *complete toolset* for cloud native applications and stacks at scales from small to large. This enables customers to adopt good tools faster, and be less at risk of confusion and doubt. +​ +We need to flesh out the portfolio of projects needed by users to succeed with cloud-native computing. It's pretty clear where remaining gaps in the project portfolio are. We should try to fill some of those, and at least document the rest. We can make more WGs to help with a few of those. (Note that “detailed architecture and stack” can be a Project) +​ +## Above All We Want To Help Projects +​ +_Principle: Our top priority is helping high-quality high-velocity cloud native open source projects be the main driver of customer adoption and success_ + +We want to be able to say that CNCF is a net positive for big & small projects. Doing so requires more coordination with project leads. +​ +Projects needs include test automation and CI, cloud resources to test on, clear documentation, per-project marketing & evangelism, roadmaps for interop, advice from experts on governance and scalability. And we need to make sure project contributors see what value they are getting & are not afraid to ask for help! +​ +Prose \ No newline at end of file From e706fc24eaf075c5dd64c8306ada9426a7b6d9c6 Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Sun, 17 Sep 2017 22:40:46 -0400 Subject: [PATCH 02/27] Minor edits Signed-off-by: Dan Kohn --- principles.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/principles.md b/principles.md index 3852641..9a9fa84 100644 --- a/principles.md +++ b/principles.md @@ -144,6 +144,4 @@ _Principle: Our top priority is helping high-quality high-velocity cloud native We want to be able to say that CNCF is a net positive for big & small projects. Doing so requires more coordination with project leads. ​ -Projects needs include test automation and CI, cloud resources to test on, clear documentation, per-project marketing & evangelism, roadmaps for interop, advice from experts on governance and scalability. And we need to make sure project contributors see what value they are getting & are not afraid to ask for help! -​ -Prose \ No newline at end of file +Project needs may include test automation and CI, cloud resources to test on, clear documentation, per-project marketing & evangelism, roadmaps for interop, and advice from experts on governance and scalability. And we need to make sure project contributors see what value they are getting & are not afraid to ask for help! From a1ce808daf0e31f3aa4d8bca5c3d1e5b4fb0467d Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Sun, 17 Sep 2017 22:57:42 -0400 Subject: [PATCH 03/27] Spacing Signed-off-by: Dan Kohn --- principles.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/principles.md b/principles.md index 9a9fa84..0a69e44 100644 --- a/principles.md +++ b/principles.md @@ -90,7 +90,7 @@ The CNCF is a badge of quality and velocity. CNCF projects should be on a path t _Principle: CNCF promotes interoperability via interfaces that get real-world use_ ​ Users and vendors both want as little friction as possible when it comes to integration. Taking any two projects and putting them into a larger stack, product, platform, solution, etc., is always easier when this is the case. For example, cloud native storage vendors want as few moving parts as possible when it comes to making their products and services work with the various emerging container platforms. At the same time, the world is littered with the untouchable remains of failed ‘standards’ that promised to provide interoperability but did not get traction. -​ +​ In the CNCF we like projects that are getting traction and may go on to become widespread and popular with end users and the ecosystem. We apply this thinking to the area normally covered by ‘standards’ including specifications for APIs, SPIs, protocols, etc. Where a good interface exists we are happy to use it if our users like it, but we are not compelled to do so. ​ We want markets and users to drive interop, not committees. We want to help real-world use happen faster, and foster collaboration. We do not wish to become gated on committees. @@ -127,13 +127,13 @@ CNI fits all of the above requirements. There is 1) a specification and it is co CNI is a software project, but the centerpiece of that project is the set of interfaces documented in the specification. Those interfaces live in the CNI Project. By the principle of interoperability, the existence of multiple CNI implementations is encouraged. Those implementations will use the interface definition from CNI as the source of truth. ​ ### Example: OCI -​ +​ OCI is not in the CNCF. The OCI project operates according to the norms of international standards bodies and has a clear primary goal: to provide a document that describes a standard set of interfaces for a container runtime and label this as 1.0. Nothing else is required. ​ ## We Want a Comprehensive Toolchain ​ _Principle: users don’t need to look beyond the CNCF for cloud native app tooling_ -​ +​ Grand vision: CNCF should identify, facilitate and promote a *complete toolset* for cloud native applications and stacks at scales from small to large. This enables customers to adopt good tools faster, and be less at risk of confusion and doubt. ​ We need to flesh out the portfolio of projects needed by users to succeed with cloud-native computing. It's pretty clear where remaining gaps in the project portfolio are. We should try to fill some of those, and at least document the rest. We can make more WGs to help with a few of those. (Note that “detailed architecture and stack” can be a Project) From c0f999979c6fca5661be48600883f5e8974ba941 Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Sun, 17 Sep 2017 23:04:08 -0400 Subject: [PATCH 04/27] Fix header --- principles.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/principles.md b/principles.md index 0a69e44..49bd061 100644 --- a/principles.md +++ b/principles.md @@ -1,9 +1,9 @@ # CNCF TOC Goals and Principles -​ + _Version 0.9, September 17, 2017 Approved by TOC on: TBD Approved by GB on: TBD_ -​ + [TOC Operating Principles](#toc-operating-principles) [We Are Project-Centric](#we-are-project-centric) [Projects Are Self-Governing](#projects-are-self-governing) From 306058175975ef747b100bb089a0fe3740571da2 Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Sun, 17 Sep 2017 23:06:39 -0400 Subject: [PATCH 05/27] Removed non-breaking spaces --- principles.md | 98 +++++++++++++++++++++++++-------------------------- 1 file changed, 49 insertions(+), 49 deletions(-) diff --git a/principles.md b/principles.md index 49bd061..c198766 100644 --- a/principles.md +++ b/principles.md @@ -12,28 +12,28 @@ Approved by GB on: TBD_ [Not a Standards Body](#not-a-standards-body) [We Want a Comprehensive Toolchain](#we-want-a-comprehensive-toolchain) [Above All We Want To Help Projects](#above-all-we-want-to-help-projects) -​ + ## TOC Operating Principles -​ + Now that CNCF has been active for over a year we want to start writing down what we have learned. Future TOCs can still make changes, but there will at least be documented precedent. -​ + ### We Are Project-Centric -​ + _Principle: If it can be on a modern public source code control system, then it can be a project. And we put projects front and center._ -​ + CNCF is a home for several kinds of “project” where community collaboration furthers the goals of the CNCF community: 1. Open source software projects, e.g., Prometheus. 1. Projects that develop interface and/or schema specifications (e.g., [CNI](https://github.com/containernetworking/cni), reference implementations, conformance tests, adaptors, etc., in order to facilitate interoperability. 1. Reference materials, such as architectures, stacks, guides, docs. ## Projects Are Self-Governing -​ + _Principle: Minimal Viable Governance_ -​ + Our expectations around governance and support are all predicated on the notion that a CNCF project works like a typical, modern “community-owned” open source software project, such as a person might discover hosted on GitHub. That means that it has ‘committers’ and shared ownership using source code control, etc. People who want the CNCF to support their ‘thing’ need to make it into a project and support “GitHub-style” communities. (Though please note that CNCF projects don't actually need to live on GitHub.) -​ + In the GitHub era, open projects are able to get a lot “done” without outside help. The CNCF does not want to get in the way of that. This starts with “minimal viable governance”. -​ + - The CNCF, TOC, and GB are available for help if it is asked for. - But: we do not want to impose bureaucracy on projects because that will slow them down. - Minimal viable governance also means that the TOC does not step in at a tactical level to overrule project leads’ decisions. @@ -41,19 +41,19 @@ In the GitHub era, open projects are able to get a lot “done” without outsid - There is a formal & regulated system of [Graduation Criteria](https://www.cncf.io/projects/graduation-criteria/) for CNCF Projects - The TOC/CNCF want the ability to intervene if things go really wrong - i.e., project leads are stuck and cannot fix things. - Provide a template for new projects, a set of best practices to help jump-start the task of setting up a new project. -​ + ### Draft Public Statement for website -​ + The CNCF is committed to helping its member projects succeed, but without dictating or micromanaging how the projects are run. To that end, it requires only minimal viable governance criteria: a [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) with neutral processes for resolving conflicts, a documented governance model that includes a contribution-based process by which contributors can become committers or maintainers, and a clear definition of the top-level project leadership, with which the foundation will engage and inform and from which it may receive requests for funding and support. Once a project has graduated from incubation, new governance requirements cannot be imposed without consent of the project, except where legally required. -​ + ## What We're Looking For -​ + We are looking for high-quality, high-velocity projects that fit ‘cloud native’. -​ + _Principle: Great projects already have many ingredients to succeed. First: do no harm._ -​ + Identify projects that have a real shot at being a useful tool in the evolving box of cloud native technology. This is a mix of mature and early-stage projects. Early stage may not have all the criteria we want: diverse contributor bases, formalized governance, interoperability, cloud-native designs, quality bar, etc. -​ + Some considerations: - Transparent, consistent technical and governance quality bar for [graduation](https://www.cncf.io/projects/graduation-criteria/) from incubation - Has users, preferably in production; is a high quality, high-velocity project @@ -62,39 +62,39 @@ Some considerations: - Is useful for cloud native deployments & ideally, is architected in a cloud native style - Has an affinity for how CNCF wants to operate - Charter Section 9(e): _New open source projects initiated in CNCF shall complete a project proposal template adopted by the TOC and be approved by the TOC for inclusion in CNCF. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project, the governance proposed for the project and identify alignment with CNCF’s role and values_ -​ + ## No Kingmakers & One Size Does Not Fit All -​ + _Preamble:_ 1. Many problems in technology have more than one solution. Markets are good at finding them. There may be multiple good OSS projects for solving a problem that are optimized for different edge cases. 1. Often multiple solutions get widespread use, for example, because they are optimized for different constraints. We don’t want to get in the way of that by insisting that one technology is “the answer” for each functional gap that we can identify today. We believe that the market and user community provide a good mechanism for pushing the most appropriate projects forward over time. We want projects to enjoy the support of the CNCF during that process. 1. There is no “one true stack”, cloud native applications cover many different use cases with different needs. Many architectures are reasonable: from 12-factor to microservice, to stateful or data-intensive, to others. And there are many scales from one node to many, from low to high latency, etc. So “one size does not fit all”. -​ + _Principles:_ 1. No kingmakers. The TOC picks projects with a real chance of achieving widespread use, and it does not pick a winner in each category. Similar or competitive projects are not excluded for reasons of overlap. 1. No one stack. The TOC does not pick a “winning stack” - i.e., vertically integrated set of projects as a solution for multiple application problems. Instead by encouraging interop, we hope that a range of patterns & “stacks” will emerge. -​ + Via the “no kingmakers” principle and “what is a project”, the CNCF may support several projects which show how a ‘stack’ is a solution to certain use cases. For example, some stacks might use a container orchestrator. Other stacks might show how to integrate monitoring with other “observability” technologies, for cloud native apps regardless of their orchestration model. -​ + This means that the CNCF is not promoting a single, monolithic stack of technologies. -​ + The CNCF is a badge of quality and velocity. CNCF projects should be on a path to being tools that users can trust, broadly work together, and that meet other cloud native criteria. But the CNCF badge does not mean “this is the standard tool”. -​ + - Overlapping projects are ok, especially where they make significantly different design tradeoffs - Who to pick: The market is too young for us to pick winners - sometimes we shall identify several really promising tools that overlap in function. Let's aim for eventual consistency based on real community use, and not create early deadlocks over "which one tool is best". - CNCF resources, both time and money, to be extremely limited, so we do need to choose carefully, and therefore should do some reasonable due diligence, including considering alternative projects. - Overall the TOC will try to maintain a public roadmap or “backlog” where it sees interesting projects emerging, or space for “RFPs”, and “WGs”. While not a hard and fast document, this will help make dialogue with the community more transparent & efficient. -​ + ## Not a Standards Body -​ + _Principle: CNCF promotes interoperability via interfaces that get real-world use_ -​ + Users and vendors both want as little friction as possible when it comes to integration. Taking any two projects and putting them into a larger stack, product, platform, solution, etc., is always easier when this is the case. For example, cloud native storage vendors want as few moving parts as possible when it comes to making their products and services work with the various emerging container platforms. At the same time, the world is littered with the untouchable remains of failed ‘standards’ that promised to provide interoperability but did not get traction. -​ + In the CNCF we like projects that are getting traction and may go on to become widespread and popular with end users and the ecosystem. We apply this thinking to the area normally covered by ‘standards’ including specifications for APIs, SPIs, protocols, etc. Where a good interface exists we are happy to use it if our users like it, but we are not compelled to do so. -​ + We want markets and users to drive interop, not committees. We want to help real-world use happen faster, and foster collaboration. We do not wish to become gated on committees. -​ + We should focus on areas of rough 'de facto' agreement, under the proviso that early markets are also diverse. Possible areas to target: - CNI - network - CSI - storage @@ -103,45 +103,45 @@ We should focus on areas of rough 'de facto' agreement, under the proviso that e - CLI - logging - Spiffe - (there is demand for some kind of serverless-related event scheme) -​ + ### How CNCF works with interface definitions like CNI, vs. standards efforts like OCI -​ + The world has a number of recognized international standards bodies such as IETF and W3C. CNCF is not playing the role of a standards body. By contrast, OCI is a standards body. -​ + CNCF may develop written materials in the style of the current CNI interface document, or in the style of an IETF RFC for example. These CNCF “specification” materials are not “standards”. It is in future possible that an independent and recognized international standards body takes a CNCF document as “upstream” and evolves it into a standard via (e.g.) the IETF process. The CNCF is morally supportive of independent parties doing this, but does not see this work as its own responsibility. For that matter, to date, no such exercise is in process. -​ + In general CNCF specifications will evolve as “living documents” side by side with the CNCF OSS projects that adopt them. This means they are “dynamic and fast-moving” whereas a typical IETF standard is ”static” and not subject to frequent updates & new releases. -​ + For the avoidance of doubt: Any written “specification” materials in CNCF shall have the same status as CNCF open source software and project technical docs. That is to say that specifications shall be updated and release versioned according to the conventions of a CNCF open source project. -​ + ### Important: Principle of Interoperability -​ + CNCF values this highly: that for any given ‘specification’, multiple implementations exist. Those implementations will use the project’s specification as the source of truth. -​ + Moreover, CNCF shall not claim interoperability if there is only one implementation. -​ + ### Example: CNI -​ + CNI fits all of the above requirements. There is 1) a specification and it is co-developed with 2) a library (libcni) and 3) ecosystem-contributed plugins. Collectively (1-3) form “the CNI Project”. In the future, CNI might include a compliance test suite which can be run against those implementations. -​ + CNI is a software project, but the centerpiece of that project is the set of interfaces documented in the specification. Those interfaces live in the CNI Project. By the principle of interoperability, the existence of multiple CNI implementations is encouraged. Those implementations will use the interface definition from CNI as the source of truth. -​ + ### Example: OCI -​ + OCI is not in the CNCF. The OCI project operates according to the norms of international standards bodies and has a clear primary goal: to provide a document that describes a standard set of interfaces for a container runtime and label this as 1.0. Nothing else is required. -​ + ## We Want a Comprehensive Toolchain -​ + _Principle: users don’t need to look beyond the CNCF for cloud native app tooling_ -​ + Grand vision: CNCF should identify, facilitate and promote a *complete toolset* for cloud native applications and stacks at scales from small to large. This enables customers to adopt good tools faster, and be less at risk of confusion and doubt. -​ + We need to flesh out the portfolio of projects needed by users to succeed with cloud-native computing. It's pretty clear where remaining gaps in the project portfolio are. We should try to fill some of those, and at least document the rest. We can make more WGs to help with a few of those. (Note that “detailed architecture and stack” can be a Project) -​ + ## Above All We Want To Help Projects -​ + _Principle: Our top priority is helping high-quality high-velocity cloud native open source projects be the main driver of customer adoption and success_ We want to be able to say that CNCF is a net positive for big & small projects. Doing so requires more coordination with project leads. -​ + Project needs may include test automation and CI, cloud resources to test on, clear documentation, per-project marketing & evangelism, roadmaps for interop, and advice from experts on governance and scalability. And we need to make sure project contributors see what value they are getting & are not afraid to ask for help! From 89bb4c4fcf2373509515f1100435e106623d9a63 Mon Sep 17 00:00:00 2001 From: Quinton Hoole Date: Tue, 3 Oct 2017 15:03:31 -0700 Subject: [PATCH 06/27] Add technical due diligence guidelines. --- process/due-diligence-guidelines.md | 147 ++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 process/due-diligence-guidelines.md diff --git a/process/due-diligence-guidelines.md b/process/due-diligence-guidelines.md new file mode 100644 index 0000000..fc0e78a --- /dev/null +++ b/process/due-diligence-guidelines.md @@ -0,0 +1,147 @@ +# Due Diligence Guidelines + +This page provides guidelines to those leading or contributing to due +diligence exercises performed by or on behalf of the Technical +Oversight Committee of the CNCF. + +## Introduction + +Part of the evaluation process in deciding upon initial or continued +inclusion of projects into the CNCF is a Technical Due Diligence +('Tech DD') exercise. Ultimately the voting members of the TOC will, +on the basis of this and other information, vote for or against the +inclusion of each project at the relevant time. + +## Leading a Technical Due Diligence + +### Primary Goals + +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://www.cncf.io/projects/graduation-criteria/) for +inception, 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. + +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 +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/toc-principles/principles.md), + the [project proposal process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc), + the [graduation criteria](https://www.cncf.io/projects/graduation-criteria/) + 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/master/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) + (both successful and unsuccessful) to help calibrate your expectations. +* Verify that all of the basic [project proposal requirements](https://github.com/cncf/toc/blob/master/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://www.cncf.io/projects/graduation-criteria/) and for each item, + decide for yourself whether or not you have enough info 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. + * 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 +due diligence exercise involves validating any claims made there, +verifying adequate coverage of the topics, and possibly summarizing +the detail where necessary. + +#### Technical + +* 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: + * 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. + * 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 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 HA? 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? +* 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? + +#### Project + +The key high-level questions that the voting TOC members will be looking to have answered are (from the [graduation criteria](https://www.cncf.io/projects/graduation-criteria/): + +* Do we believe this is a growing, thriving project with committed contributors? +* Is it aligned with CNCF's values and mission? +* Do we believe it could eventually meet the graduation criteria? +* Should it start at the inception level or incubation level? + +Some details that might inform the above include: + +* Does ithe project have a sound, documented process for source control, issue tracking, release management etc. +* Does it have a documented process for adding committers? +* 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? + 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)? +* 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. +* Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc. +* Do they make it easy to contribute to the project? If not, what are the main obstacles? +* Are there any especially difficult personalities to deal with? How is this done? Is it a problem? +* What is the rate of ongoing contributions to the project (typically in the form of merged commits). + +#### 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? +* 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? + +#### 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? +* 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. + +#### 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, + 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 + 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. \ No newline at end of file From d8d8caddd2f15ab2d44b1785ff3fb918ea3d7d77 Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 27 Nov 2017 08:51:53 -0600 Subject: [PATCH 07/27] Update TOC principles to v1.0 --- principles.md => PRINCIPLES.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename principles.md => PRINCIPLES.md (99%) diff --git a/principles.md b/PRINCIPLES.md similarity index 99% rename from principles.md rename to PRINCIPLES.md index c198766..7011bb3 100644 --- a/principles.md +++ b/PRINCIPLES.md @@ -1,7 +1,7 @@ -# CNCF TOC Goals and Principles +# CNCF TOC Principles -_Version 0.9, September 17, 2017 -Approved by TOC on: TBD +_Version 1.0, Nov 27, 2017 +Approved by TOC on: Nov 27, 2017 Approved by GB on: TBD_ [TOC Operating Principles](#toc-operating-principles) From 27128476ba40eec84dd754c269e77810bed26914 Mon Sep 17 00:00:00 2001 From: Ken Owens Date: Mon, 27 Nov 2017 15:29:30 -0600 Subject: [PATCH 08/27] Create Open Policy Agent Proposal for Review --- proposals/Open Policy Agent | 182 ++++++++++++++++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 proposals/Open Policy Agent diff --git a/proposals/Open Policy Agent b/proposals/Open Policy Agent new file mode 100644 index 0000000..0c0c2fc --- /dev/null +++ b/proposals/Open Policy Agent @@ -0,0 +1,182 @@ +# Project Description + +Every organization has unique policies that affect the entire stack. These policies are vital to long term success because they codify +important requirements around cost, performance, security, legal regulation, and more. At the same time, organizations often rely on +tribal knowledge and documentation to ensure that policies are enforced correctly. While these approaches are known to be error prone, +they exist because systems frequently lack the flexibility and expressiveness required to automate policy enforcement. + +The Open Policy Agent (OPA) is a general-purpose policy engine that enables unified, context-aware policy enforcement across the stack. +OPA empowers administrators with greater control and flexibility so that organizations can automate policy enforcement at any layer. + +At the core of OPA is a high-level declarative language (and runtime) that allows administrators to enforce policies across multiple +domains such as API authorization, admission control, workload placement, storage, and networking. OPA’s language is purpose-built for +expressing policy decisions. The language has rich support for processing complex data structures as well as performing search and +aggregation across context required for policy decisions. The language also provides support for encapsulation and composition so that +complex policies can be shared and re-used. Finally, the language includes a standard library of built-in functions for performing math +operations, string manipulation, date/time parsing, and more. + +With OPA, policy decisions are decoupled from applications and services so that policy logic can be modified easily and upgraded +on-the-fly without requiring expensive, time consuming development and release cycles. + +OPA provides simple APIs to offload policy decisions from applications and services. Policy decisions are computed by OPA and returned +to callers as structured data. Callers integrate with OPA by executing policy queries that can include arbitrary input values. For +example, an API gateway might supply incoming API requests as input and expect boolean values (representing allow/deny decisions) as +output. On the other hand, a container orchestrator might supply workload resources as input and expect a map of clusters and weights +to drive workload placement as output. See the appendix for sample policies that cover these use cases. + +OPA itself is written in Go and can be integrated as a library, host-level daemon, or sidecar container. OPA provides APIs to load and +manage policies as well as external data. Finally, OPA provides rich tooling to support the development, testing, and debugging of +policies. + +Since the initial release in July 2016, OPA’s mission has been to provide a powerful building block that enables policy-based control +across the stack. OPA’s roadmap for the next 12 months includes improvements to the language, integration with Google’s CEL, expansion +of the standard policy library, as well as continued hardening and performance optimization. + +**Sponsor from TOC:** Ken Owens + +**Preferred Maturity Level:** Inception + +**License:** Apache License v2 + +# Source Control +https://github.com/open-policy-agent/opa +https://github.com/open-policy-agent/library + +# External Dependencies + +github.com/ghodss/yaml MIT License +github.com/gorilla/mux BSD 3-clause "New" or "Revised" License +github.com/mattn/go-runewidth MIT License +github.com/olekukonko/tablewriter MIT License +github.com/peterh/liner MIT License +github.com/pkg/errors BSD 2-clause "Simplified" License +github.com/sirupsen/logrus MIT License +github.com/spf13/cobra Apache License 2.0 +github.com/spf13/pflag BSD 3-clause "New" or "Revised" License +golang.org/x/crypto/ssh/terminal BSD 3-clause "New" or "Revised" License +golang.org/x/sys/unix BSD 3-clause "New" or "Revised" License +gopkg.in/fsnotify.v1 BSD 3-clause "New" or "Revised" License +gopkg.in/yaml.v2 Apache License 2.0 + + +**Initial Committers:** Torin Sandall and Tim Hinrichs from Styra (since creation), Tristan Swadell from Google (since May 2017) + +**Infrastructure Requests:** None initially. CI is currently hosted on Travis and covered by the free tier for open source projects. In +the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the OPA project. + +**Communication Channels:** +Slack: http://slack.openpolicyagent.org + +**Issue Tracker:** https://github.com/open-policy-agent/opa/issues + +**Website:** http://www.openpolicyagent.org + +# Release Methodology and Mechanics + +We currently use numbered releases with the changelog and binaries published to https://github.com/open-policy-agent/opa/releases. +The release process is partially automated with manual portions assisted by scripts. The current release process is documented here: +https://github.com/open-policy-agent/opa/blob/master/docs/devel/RELEASE.md. The release schedule is somewhat ad-hoc, aligned around +large feature boundaries. + +**Social Media Accounts:** +Twitter: https://twitter.com/openpolicyagent + +# Community Size and any Existing Sponsorship + +Adopters: +Netflix +Medallia +Schuberg Phillis +Huawei +More: At least one large financial institution and one large online retailer is testing OPA + +Integrations: +Kubernetes (Use cases: federated resource placement, admission control) +Docker (Use cases: Docker engine authorization) +Istio (Use cases: microservice API authorization) +Linkerd (Use cases: microservice API authorization) +OpenSDS (Use cases: storage scheduling) +Terraform (Use cases: risk management on terraform plans) +PAM (Use cases: SSH and sudo authorization) +Cloud Foundry buildpack to enable microservice API authorization + +**Sponsors** +https://www.styra.com +https://www.firebase.com (Google) + +**Numbers:** +3 active contributors currently (2 from Styra, 1 from Google), with 8 other contributors over past 12 months. +80 stars +49 members on Slack +31 releases + +# Statement of Alignment with CNCF Mission + +As cloud native technology matures and enterprise adoption increases, the need for policy-based control has become apparent. OPA +provides a powerful building-block that enables fine-grained, expressive policy enforcement. As such, we think that OPA would be a +great for fit for the CNCF + +# Benefits to the CNCF + +The ecosystem must provide solutions to control who can do what across microservice deployments because legacy approaches to access +control do not satisfy the requirements of modern environments. OPA provides a purpose-built language and runtime that can be used to +author and enforce authorization policy. As such, we feel that OPA will complement the CNCF’s portfolio and help accelerate adoption of +cloud native technology in enterprises. In the longer term, we think that enterprises will benefit from a unified approach to policy +enforcement can be applied across the stack. + +# What does OPA need from the CNCF + +OPA needs a well respected, vendor-neutral home that can help serve as a rallying point around policy as code. In addition to increased +visibility, we hope that inclusion in the CNCF will foster communication between OPA and other projects in the ecosystem. As the project +grows, we would want to leverage the CNCF’s expertise around project governance and community standards as those are fundamental to the +long term success of the project. + +The project does not have any infrastructure requests at this time. CI is currently hosted on Travis and covered by the free tier for +open source projects. In the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the +OPA project. + +# Appendix A: REST API Authorization Example + +This sample shows two simple rules that enforce an authorization policy on an API that serves salary data. In English, the policy says +that employees can see their own salary and the salary of any of their reports. + +allow { + input.method = "GET" + input.path = ["salary", employee_id] + input.user = employee_id +} + + +allow { + input.method = "GET" + input.path = ["salary", employee_id] + input.user = data.management_chain[employee_id][_] +} + + +The first rule allows employees to GET their own salary. The rule shows how you can use variables in rules. In that rule, employee_id is +a variable that will be bound to the same value across the last two expressions. + +The second rule allow employees to GET the salary of their reports. The rule shows how you can access arbirary context (e.g., JSON data) +inside the policy. The data may loaded into the policy engine (and cached) or it may be external and fetched dynamically. + + +# Appendix B: Cluster Placement Example + +This sample shows a simple rule that generates a set of clusters that a workload may be deployed to. The workload is provided as input +to policy. In English, the policy says that workloads must be placed on clusters that satisfy the workload’s jurisdiction requirements. + +desired_clusters = {name | + cluster = data.clusters[name] + satisfies_jurisdiction(input.deployment, cluster) +} + + +satisfies_jursidiction(deployment, cluster) { + deployment.jurisdiction = "europe" + startswith(cluster.region, "eu") +} else { + not deployment.jurisdiction +} + +This example shows how logic can be composed across rules and functions. From dc63ecbec8f10a558ba2d62a6795f02b6d19a66f Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 27 Nov 2017 15:46:34 -0600 Subject: [PATCH 09/27] Update agenda for Dec 5th/7th --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 661899f..4fac50c 100644 --- a/README.md +++ b/README.md @@ -116,7 +116,8 @@ If you're interested in presenting at a TOC call about your project, please open * **October 17, 2017**: TOC Principles / GB (Todd Moore) and OpenMetrics Update * **November 7, 2017**: Istio, SPIFFE.io and Serverless WG * **November 14, 2017**: [OPA](http://www.openpolicyagent.org/) and Storage WG/CSI and Project Graduation/Health Reviews (Kubernetes, Prometheus) -* **December 5, 2017**: Rook +* **December 5, 2017**: Rook, OpenOverlay +* **December 7, 2017**: KubeCon/CloudNativeCon F2F * **January 16, 2017**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) ## Meeting Minutes @@ -163,3 +164,5 @@ If you're interested in presenting at a TOC call about your project, please open * [October 17th, 2017](https://goo.gl/hH6fS4) * [November 7th, 2017](https://goo.gl/LoKyV5) * [November 14th, 2017](https://goo.gl/vKbawR) +* [December 5th, 2017](https://goo.gl/77pMFY) +* [December 7th, 2017](https://goo.gl/Ugo7F9) From 1fb4651317a6f4fee56513120ec68c8a50f1b4bb Mon Sep 17 00:00:00 2001 From: Bassam Tabbara Date: Thu, 13 Jul 2017 21:57:18 -0700 Subject: [PATCH 10/27] proposals: add rook --- proposals/rook.adoc | 155 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 proposals/rook.adoc diff --git a/proposals/rook.adoc b/proposals/rook.adoc new file mode 100644 index 0000000..47a64bf --- /dev/null +++ b/proposals/rook.adoc @@ -0,0 +1,155 @@ +== Rook + +*Name of project:* Rook + +*Description:* + +Rook is an open source orchestrator for distributed storage systems running in cloud native environments. + +Distributed storage systems are inherently complex -- they define strong consistency and durability guarantees that must hold even when scaling, upgrading, and running maintenance operations. They require careful provisioning and balancing of resources to optimize access to data and maintain durability. It's common for such systems to require dedicated administrators. + +Rook turns distributed storage systems into self-managing, self-scaling, and self-healing storage services. It does this by automating the tasks of a storage administrator including deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. Rook leverages the power of the underlying cloud-native container management, scheduling, and orchestration platform to perform its duties. + +Rook integrates deeply into cloud native environments leveraging extension points and providing a seamless experience for scheduling, lifecycle management, resource management, security, monitoring, and user experience. + +Rook is currently in alpha state and has focused initially on orchestrating Ceph on-top of Kubernetes. Ceph is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters. Rook is planning to be production ready by Dec'17 for block storage deployments on-top of Kubernetes. + +With community participation, Rook plans to add support for other storage systems beyond Ceph and other cloud native environments beyond Kubernetes. The logic for orchestrating storage systems can be reused across storage backends. Also having common abstractions, packaging, and integrations reduces the burden of introducing storage back-ends and improves the overall experience. + +*Statement on alignment with CNCF mission:* + +Rook is well-aligned with CNCF's goals and mission of promoting cloud-native computing. Rook adheres to the core principles of cloud-native systems: container packaged, micro-services oriented, and dynamically managed. + +Rook is complimentary to other CNCF projects like Kubernetes and Prometheus. It integrates and extends Kubernetes and has a strong alignment on design and architecture. Rook is itself implemented as a controller (reconciling desired and actual state), and uses the Kubernetes API extensively to perform its functions. Rook exposes monitoring and instrumentation via Prometheus. + +Rook brings distributed storage services into cloud-native environments beyond what has been done to date with plugins (including CSI). We believe that by running storage systems on-top of cloud-native environments we will be a step closer to the multi-cloud vision. + +*Sponsor / Advisor from TOC:* Benjamin Hindman + +*Unique identifier:* rook + +*Preferred maturity level:* inception + +*License:* Apache License v2.0 + +*Source control repositories:* https://github.com/rook/rook + +*External Dependencies:* + +Golang package dependencies: + +* https://github.com/coreos/pkg (Apache v2.0) +* https://github.com/go-ini/ini (Apache v2.0) +* https://github.com/google/uuid (BSD 3-Clause) +* https://github.com/gorilla/mux (Apache v2.0) +* https://github.com/jbw976/go-ps (Apache v2.0) +* https://github.com/kubernetes/api (Apache v2.0) +* https://github.com/kubernetes/apiextensions-apiserver (Apache v2.0) +* https://github.com/kubernetes/apimachinery (Apache v2.0) +* https://github.com/kubernetes/apiserver (Apache v2.0) +* https://github.com/kubernetes/client-go (Apache v2.0) +* https://github.com/kubernetes/code-generator (Apache v2.0) +* https://github.com/kubernetes/kubernetes (Apache v2.0) +* https://github.com/kubernetes/utils (Apache v2.0) +* https://github.com/prometheus/client_golang (Apache v2.0) +* https://github.com/rook/operator-kit (Apache v2.0) +* https://github.com/spf13/cobra (Apache v2.0) +* https://github.com/spf13/pflag (BSD 3-Clause) + +Binary dependencies packaged into Rook containers: + +* Ceph (mostly LGPL 2.0) - https://github.com/ceph/ceph + +*Initial Committers:* + +* Bassam Tabbara (Upbound) +* Jared Watts (Quantum) +* Travis Nielsen (Quantum) + +Current list is on https://github.com/rook/rook/blob/master/MAINTAINERS. Maintainers are updated according to the following rules https://github.com/rook/rook/blob/master/MAINTAINERS_RULES.md + +*Infrastructure requests (CI / CNCF Cluster):* + +CI currently at https://jenkins.rook.io but could move to CNCF CI. + +Planning to use CNCF cluster for integration and performance testing at scale. + +*Communication Channels:* + +* Slack: https://rook-slackin.herokuapp.com +* Gitter: https://gitter.im/rook/rook (deprecated) +* Google Groups: https://groups.google.com/forum/#!forum/rook-dev +* Email: mailto:info@rook.io[info@rook.io] + +*Issue tracker:* https://github.com/rook/rook/issues + +*Website:* https://rook.io + +*Release methodology and mechanics:* + +Major releases roughly every two months, minor releases as needed. + +*Social media accounts:* + +* Twitter: @rook_io + +*Existing sponsorship*: Quantum and Upbound + +Statement from Quantum: In 2016 as part of ongoing product development work we identified the need for richer implementations of storage technologies in Cloud Native systems. As this work progressed we felt that it was evolving into a core component of the platform architecture and chose to open-source our work. Since then Quantum has continued to invest in both the Rook technologies and launching Rook as a vibrant open source project. Internally we are utilizing Rook as well as many other Cloud Native technologies to build systems relevant to our businesses. We firmly believe that a vibrant Rook project and ecosystem is in our and the community’s best interests. As the project continues to grow our role will become less significant in terms of strategy and direction and we think this evolution and adopting well established governance principles will strengthen the project. + +*Community size:* + +* Rook was open sourced Nov'2016 +* 1785+ stars +* 40+ contributors +* 155+ forks +* 135+ on slack +* 600K+ container pulls (quay.io), 50K+ container pulls (docker) + +*Comparison with gluster-kubernetes and ceph-container*: + +Existing approaches to running distributed storage systems like Ceph and Gluster focus primarily on packaging in containers, initial deployment, and bootstrapping. There is no central controller that is responsible for ongoing operations, dynamic management and maintenance of such storage systems. While some of these operations can be handled by the orchestration platform itself (for example, scaling through stateful-sets in Kubernetes) the approach only covers a small subset of the administration tasks and does not take into account the inherent constraints and guarantees of the backend storage system. For example, growing a cluster in Ceph not only requires scheduling more storage nodes but also updating the storage topology to optimize data access and improve durability all without breaking consistency guarantees. Rook's storage controller is responsible for ongoing and dynamic management of the storage system and it does so in a storage backend specific way. + +Rook introduces new abstractions for storage clusters, pools, volumes, volume-attachements, snapshots and others that are extension points of the cloud-native environment. This leads to a deeper integration into cloud-native environments. Other approaches like gluster-kubernetes and ceph-container rely on their own storage API for management and integrate primarily at the volume plugin level, and not the storage service level. + +Finally Rook is designed to run primarily as an application of cloud-native systems minimizing (and eventually eliminating all dependencies) on the host platform. For example, Rook runs using the Kubernetes networking, whereas other approach like ceph-container require host networking. + +*Comparison with minio*: + +Minio is a distributed object store that is designed for cloud applications. Minio focuses on simplicity of deployment and operations. Rook could orchestrate Minio just like it does with Ceph's object store (rgw). Some of the operation tasks that Rook would perform include initial deployment, dealing with erasure-coding and multi-tenancy constraints, locking and dsync quorum, topology, and healing storage nodes on loss events. Also Rook exposes object store abstractions that could be used by minio for a deeper integration into cloud-native environments like Kubernetes. + +*Production usage*: + +Rook is in alpha and has little production usage. The first stable release of Rook is expected in Dec'2017. Ceph is production ready and is deployed in large-scale production environments. There are a number of companies and users that have deployed Rook in testing and staging environments (on-premise and public cloud), and a few that have deployed it in production (see quotes below). Quantum Corp. (the current sponsor of the Rook project) plans to deploy Rook within commercial enterprise storage appliances early next year. + + +[quote, Brandon Philips, CTO - CoreOS] +CoreOS helps companies ensure their critical application infrastructure is able to run free from cloud lock-in with CoreOS Tectonic and Kubernetes APIs. We are encouraged to see storage systems, like Rook, emerging that build directly upon those APIs to deliver a flexible cloud-agnostic storage solution. + + +[quote, Sasha Klizhentas, CTO - Gravitational] +Gravitational team is excited to be early adopters of Rook. Rook's solid foundation makes it the leader among emerging cloud-native storage solutions. + + +[quote, Hunter Nield, CTO - Acaleph] +At Acaleph, we're excited for a true cloud-native storage platform. Having experienced the complexity of running Ceph on Kubernetes, Rook provides the stability and power of an established software-defined storage solution with ease of use of native Kubernetes integration. With the latest release of Rook, we're looking to implement as a core part of our storage platform. + + +[quote, Matt Baldwin, CTO - StackPointCloud] +I have been watching adoption of Rook grow within our 6,000+ base of Kubernetes users. We have worked with users to prototype Rook in their Deployments. As it approaches a production release, I have plans to include and support it as a part of the official Stackpoint.io offering. + + +[quote, Bryan Zubrod, Founder - Zubrod Farms] +On my farm it's important to make efficient use of resources I already have. With Rook's Kubernetes-native design I am able to use commodity hardware without sacrificing redundancy for my storage or availability of my services. That's why Rook fits perfectly in my farm's metrics and automation systems, and I follow its development closely. + + +[quote, Jason Vigil, Software Engineer - Dell/EMC] +Rook looks like a simple and easy solution for persistent storage in a Kubernetes environment. I plan to use it for upcoming projects. + + +[quote, Lucas Käldström, Founder - luxas labs] +I'm really excited to see Rook evolve to a fully production-grade system. I've used and contributed to it from an early stage and can't wait to use it in even more prod systems + + +[quote, Patrick Stadler, Software Engineer - Liip] +Utilizing hyper-converged systems with storage tightly coupled to computational resources reduces cost and operational complexity of infrastructure. This is especially true for small scale cluster deployments. The biggest challenge with Kubernetes on bare metal is providing distributed block storage. Although proprietary solutions exist, there's been a lack of well-backed open source solutions. Rook has the potential to fill this void. From 20a2e3c8cf27bce220ee4880bc287c03f45ac9d5 Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 5 Dec 2017 09:07:21 -0600 Subject: [PATCH 11/27] Remove OPA project proposal Proposals shouldn't be committed to the main repo unless approved by the TOC. All discussion should happen in a PR first. Signed-off-by: Chris Aniszczyk --- proposals/Open Policy Agent | 182 ------------------------------------ 1 file changed, 182 deletions(-) delete mode 100644 proposals/Open Policy Agent diff --git a/proposals/Open Policy Agent b/proposals/Open Policy Agent deleted file mode 100644 index 0c0c2fc..0000000 --- a/proposals/Open Policy Agent +++ /dev/null @@ -1,182 +0,0 @@ -# Project Description - -Every organization has unique policies that affect the entire stack. These policies are vital to long term success because they codify -important requirements around cost, performance, security, legal regulation, and more. At the same time, organizations often rely on -tribal knowledge and documentation to ensure that policies are enforced correctly. While these approaches are known to be error prone, -they exist because systems frequently lack the flexibility and expressiveness required to automate policy enforcement. - -The Open Policy Agent (OPA) is a general-purpose policy engine that enables unified, context-aware policy enforcement across the stack. -OPA empowers administrators with greater control and flexibility so that organizations can automate policy enforcement at any layer. - -At the core of OPA is a high-level declarative language (and runtime) that allows administrators to enforce policies across multiple -domains such as API authorization, admission control, workload placement, storage, and networking. OPA’s language is purpose-built for -expressing policy decisions. The language has rich support for processing complex data structures as well as performing search and -aggregation across context required for policy decisions. The language also provides support for encapsulation and composition so that -complex policies can be shared and re-used. Finally, the language includes a standard library of built-in functions for performing math -operations, string manipulation, date/time parsing, and more. - -With OPA, policy decisions are decoupled from applications and services so that policy logic can be modified easily and upgraded -on-the-fly without requiring expensive, time consuming development and release cycles. - -OPA provides simple APIs to offload policy decisions from applications and services. Policy decisions are computed by OPA and returned -to callers as structured data. Callers integrate with OPA by executing policy queries that can include arbitrary input values. For -example, an API gateway might supply incoming API requests as input and expect boolean values (representing allow/deny decisions) as -output. On the other hand, a container orchestrator might supply workload resources as input and expect a map of clusters and weights -to drive workload placement as output. See the appendix for sample policies that cover these use cases. - -OPA itself is written in Go and can be integrated as a library, host-level daemon, or sidecar container. OPA provides APIs to load and -manage policies as well as external data. Finally, OPA provides rich tooling to support the development, testing, and debugging of -policies. - -Since the initial release in July 2016, OPA’s mission has been to provide a powerful building block that enables policy-based control -across the stack. OPA’s roadmap for the next 12 months includes improvements to the language, integration with Google’s CEL, expansion -of the standard policy library, as well as continued hardening and performance optimization. - -**Sponsor from TOC:** Ken Owens - -**Preferred Maturity Level:** Inception - -**License:** Apache License v2 - -# Source Control -https://github.com/open-policy-agent/opa -https://github.com/open-policy-agent/library - -# External Dependencies - -github.com/ghodss/yaml MIT License -github.com/gorilla/mux BSD 3-clause "New" or "Revised" License -github.com/mattn/go-runewidth MIT License -github.com/olekukonko/tablewriter MIT License -github.com/peterh/liner MIT License -github.com/pkg/errors BSD 2-clause "Simplified" License -github.com/sirupsen/logrus MIT License -github.com/spf13/cobra Apache License 2.0 -github.com/spf13/pflag BSD 3-clause "New" or "Revised" License -golang.org/x/crypto/ssh/terminal BSD 3-clause "New" or "Revised" License -golang.org/x/sys/unix BSD 3-clause "New" or "Revised" License -gopkg.in/fsnotify.v1 BSD 3-clause "New" or "Revised" License -gopkg.in/yaml.v2 Apache License 2.0 - - -**Initial Committers:** Torin Sandall and Tim Hinrichs from Styra (since creation), Tristan Swadell from Google (since May 2017) - -**Infrastructure Requests:** None initially. CI is currently hosted on Travis and covered by the free tier for open source projects. In -the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the OPA project. - -**Communication Channels:** -Slack: http://slack.openpolicyagent.org - -**Issue Tracker:** https://github.com/open-policy-agent/opa/issues - -**Website:** http://www.openpolicyagent.org - -# Release Methodology and Mechanics - -We currently use numbered releases with the changelog and binaries published to https://github.com/open-policy-agent/opa/releases. -The release process is partially automated with manual portions assisted by scripts. The current release process is documented here: -https://github.com/open-policy-agent/opa/blob/master/docs/devel/RELEASE.md. The release schedule is somewhat ad-hoc, aligned around -large feature boundaries. - -**Social Media Accounts:** -Twitter: https://twitter.com/openpolicyagent - -# Community Size and any Existing Sponsorship - -Adopters: -Netflix -Medallia -Schuberg Phillis -Huawei -More: At least one large financial institution and one large online retailer is testing OPA - -Integrations: -Kubernetes (Use cases: federated resource placement, admission control) -Docker (Use cases: Docker engine authorization) -Istio (Use cases: microservice API authorization) -Linkerd (Use cases: microservice API authorization) -OpenSDS (Use cases: storage scheduling) -Terraform (Use cases: risk management on terraform plans) -PAM (Use cases: SSH and sudo authorization) -Cloud Foundry buildpack to enable microservice API authorization - -**Sponsors** -https://www.styra.com -https://www.firebase.com (Google) - -**Numbers:** -3 active contributors currently (2 from Styra, 1 from Google), with 8 other contributors over past 12 months. -80 stars -49 members on Slack -31 releases - -# Statement of Alignment with CNCF Mission - -As cloud native technology matures and enterprise adoption increases, the need for policy-based control has become apparent. OPA -provides a powerful building-block that enables fine-grained, expressive policy enforcement. As such, we think that OPA would be a -great for fit for the CNCF - -# Benefits to the CNCF - -The ecosystem must provide solutions to control who can do what across microservice deployments because legacy approaches to access -control do not satisfy the requirements of modern environments. OPA provides a purpose-built language and runtime that can be used to -author and enforce authorization policy. As such, we feel that OPA will complement the CNCF’s portfolio and help accelerate adoption of -cloud native technology in enterprises. In the longer term, we think that enterprises will benefit from a unified approach to policy -enforcement can be applied across the stack. - -# What does OPA need from the CNCF - -OPA needs a well respected, vendor-neutral home that can help serve as a rallying point around policy as code. In addition to increased -visibility, we hope that inclusion in the CNCF will foster communication between OPA and other projects in the ecosystem. As the project -grows, we would want to leverage the CNCF’s expertise around project governance and community standards as those are fundamental to the -long term success of the project. - -The project does not have any infrastructure requests at this time. CI is currently hosted on Travis and covered by the free tier for -open source projects. In the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the -OPA project. - -# Appendix A: REST API Authorization Example - -This sample shows two simple rules that enforce an authorization policy on an API that serves salary data. In English, the policy says -that employees can see their own salary and the salary of any of their reports. - -allow { - input.method = "GET" - input.path = ["salary", employee_id] - input.user = employee_id -} - - -allow { - input.method = "GET" - input.path = ["salary", employee_id] - input.user = data.management_chain[employee_id][_] -} - - -The first rule allows employees to GET their own salary. The rule shows how you can use variables in rules. In that rule, employee_id is -a variable that will be bound to the same value across the last two expressions. - -The second rule allow employees to GET the salary of their reports. The rule shows how you can access arbirary context (e.g., JSON data) -inside the policy. The data may loaded into the policy engine (and cached) or it may be external and fetched dynamically. - - -# Appendix B: Cluster Placement Example - -This sample shows a simple rule that generates a set of clusters that a workload may be deployed to. The workload is provided as input -to policy. In English, the policy says that workloads must be placed on clusters that satisfy the workload’s jurisdiction requirements. - -desired_clusters = {name | - cluster = data.clusters[name] - satisfies_jurisdiction(input.deployment, cluster) -} - - -satisfies_jursidiction(deployment, cluster) { - deployment.jurisdiction = "europe" - startswith(cluster.region, "eu") -} else { - not deployment.jurisdiction -} - -This example shows how logic can be composed across rules and functions. From 5234b0bc4d433b8e6ab2ec234cf5d226756ff132 Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 5 Dec 2017 13:40:00 -0600 Subject: [PATCH 12/27] GB approved the TOC principles on 12/5/17 Signed-off-by: Chris Aniszczyk --- PRINCIPLES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index 7011bb3..62d7760 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -2,7 +2,7 @@ _Version 1.0, Nov 27, 2017 Approved by TOC on: Nov 27, 2017 -Approved by GB on: TBD_ +Approved by GB on: Dec 5, 2017 [TOC Operating Principles](#toc-operating-principles) [We Are Project-Centric](#we-are-project-centric) From 434ec3c8c298f2a53982baeeaab974ed2d7b300f Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 11 Dec 2017 10:21:01 -0600 Subject: [PATCH 13/27] Add CSI / Storage WG Readout Jan 16th --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 4fac50c..5e17485 100644 --- a/README.md +++ b/README.md @@ -118,7 +118,8 @@ If you're interested in presenting at a TOC call about your project, please open * **November 14, 2017**: [OPA](http://www.openpolicyagent.org/) and Storage WG/CSI and Project Graduation/Health Reviews (Kubernetes, Prometheus) * **December 5, 2017**: Rook, OpenOverlay * **December 7, 2017**: KubeCon/CloudNativeCon F2F -* **January 16, 2017**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) +* **January 16, 2017**: CSI/Storage WG Readout +* **Feb 6, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) ## Meeting Minutes From 0d84f058f41aea4382f86b3e6fa05121bae6fec2 Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 11 Dec 2017 15:21:55 -0600 Subject: [PATCH 14/27] Address comments in #71 https://github.com/cncf/toc/pull/71#issuecomment-350858244 --- PRINCIPLES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PRINCIPLES.md b/PRINCIPLES.md index 62d7760..48b6b5f 100644 --- a/PRINCIPLES.md +++ b/PRINCIPLES.md @@ -56,7 +56,7 @@ Identify projects that have a real shot at being a useful tool in the evolving b Some considerations: - Transparent, consistent technical and governance quality bar for [graduation](https://www.cncf.io/projects/graduation-criteria/) from incubation -- Has users, preferably in production; is a high quality, high-velocity project +- Has users, preferably in production; is a high quality, high-velocity project (for incubation and graduated projects). Inception level projects are targeted at earlier-stage projects to cultivate a community/technology - Has a committed and excited team that appears to understand the challenges ahead and wishes to meet them - Has a fundamentally sound design without obvious critical compromises that will inhibit potential widespread adoption - Is useful for cloud native deployments & ideally, is architected in a cloud native style From b162eb0c82484cf6ff6a638d9bc3763d92a2565d Mon Sep 17 00:00:00 2001 From: Deyuan Deng Date: Thu, 14 Dec 2017 21:18:15 +0800 Subject: [PATCH 15/27] add Deyuan Deng to toc contributor --- CONTRIBUTORS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index d2375fb..0272120 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -29,6 +29,7 @@ List below is the official list of TOC contributors, in alphabetical order: * Clinton Kitson, Dell (Clinton.Kitson@dell.com) * Dan Wilson, Concur (danw@concur.com) * Darren Ratcliffe, Atos (darren.ratcliffe@atos.net) +* Deyuan Deng, Caicloud (deyuan@caicloud.io) * Doug Davis, IBM (dug@us.ibm.com) * Drew Rapenchuk, Bloomberg (drapenchuk@bloomberg.net) * Dustin Kirkland, Canonical (kirkland@canonical.com) From c2209bf59829e97476375d261fbd5c536bad9718 Mon Sep 17 00:00:00 2001 From: Bassam Tabbara Date: Thu, 14 Dec 2017 08:13:33 -0800 Subject: [PATCH 16/27] update bassam's email --- CONTRIBUTORS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index 0272120..a57251f 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -21,7 +21,7 @@ List below is the official list of TOC contributors, in alphabetical order: * Alex Chircop, StorageOS (alex.chircop@storageos.com) * Andy Santosa, Ebay (asantosa@ebay.com) * Ara Pulido, Bitnami (ara@bitnami.com) -* Bassam Tabbara, Quantum (bassam@tabbara.com) +* Bassam Tabbara, Upbound (bassam@upbound.io) * Bob Wise, Samsung SDS (bob@bobsplanet.com) * Cathy Zhang, Huawei (cathy.h.zhang@huawei.com) * Chase Pettet, Wikimedia Foundation (cpettet@wikimedia.org) From 42ae0a152e7cbca8ef34155b0f80854b4074c9fb Mon Sep 17 00:00:00 2001 From: supereagle Date: Fri, 15 Dec 2017 10:24:57 +0800 Subject: [PATCH 17/27] fix principle link --- process/due-diligence-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/due-diligence-guidelines.md b/process/due-diligence-guidelines.md index fc0e78a..318e355 100644 --- a/process/due-diligence-guidelines.md +++ b/process/due-diligence-guidelines.md @@ -33,7 +33,7 @@ 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/toc-principles/principles.md), +* make sure you're clear on the [TOC Principles](https://github.com/cncf/toc/blob/master/PRINCIPLES.md), the [project proposal process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc), the [graduation criteria](https://www.cncf.io/projects/graduation-criteria/) and [desired cloud native properties](https://www.cncf.io/about/charter/) are. The project sponsor (a member From 91e7485b4bebf8784dbfd5f7e635526ec890183c Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Fri, 15 Dec 2017 11:04:35 -0500 Subject: [PATCH 18/27] 2018 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5e17485..92de8c9 100644 --- a/README.md +++ b/README.md @@ -118,7 +118,7 @@ If you're interested in presenting at a TOC call about your project, please open * **November 14, 2017**: [OPA](http://www.openpolicyagent.org/) and Storage WG/CSI and Project Graduation/Health Reviews (Kubernetes, Prometheus) * **December 5, 2017**: Rook, OpenOverlay * **December 7, 2017**: KubeCon/CloudNativeCon F2F -* **January 16, 2017**: CSI/Storage WG Readout +* **January 16, 2018**: CSI/Storage WG Readout * **Feb 6, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) ## Meeting Minutes From 2040d3337de92419184076268eaf6c9cd49eebda Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 9 Jan 2018 16:37:38 -0600 Subject: [PATCH 19/27] Update WG zoom meeting links --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 92de8c9..2adf9fe 100644 --- a/README.md +++ b/README.md @@ -36,10 +36,10 @@ The TOC has created the following working groups to investigate and discuss the | Working Group | Chair | Meeting Time | Minutes/Recordings | |---------------|------------------|---------------------------------------|--------------------| -| [CI](https://github.com/cncf/wg-ci) | Camille Fournier | [2nd and 4th Tue every month at 8AM PT](https://zoom.us/j/199346891) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2P3_A3ujWHSxOu1IO_bd7Zi) -| [Networking](https://github.com/cncf/wg-networking) | Ken Owens | [1st and 3rd Tue every month at 9AM PT](https://zoom.us/j/999936723) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2M_-K5n67_zTdrPh_PtTKFC) -| [Serverless](https://github.com/cncf/wg-serverless) | Ken Owens | [Thu of every week at 9AM PT](https://zoom.us/j/893315636) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2Ph7YoBIgsZNW_RGJvNlFOt) -| [Storage](https://github.com/cncf/wg-storage) | Ben Hindman | [2nd and 4th Wed every month at 8AM PT](https://zoom.us/j/158580155) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2NoiNaLVZxr-ERc1ifKP7n6) +| [CI](https://github.com/cncf/wg-ci) | Camille Fournier | [2nd and 4th Tue every month at 8AM PT](https://zoom.us/my/cncfciwg) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2P3_A3ujWHSxOu1IO_bd7Zi) +| [Networking](https://github.com/cncf/wg-networking) | Ken Owens | [1st and 3rd Tue every month at 9AM PT](https://zoom.us/my/cncfnetworkingwg) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2M_-K5n67_zTdrPh_PtTKFC) +| [Serverless](https://github.com/cncf/wg-serverless) | Ken Owens | [Thu of every week at 9AM PT](https://zoom.us/my/cncfserverlesswg) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2Ph7YoBIgsZNW_RGJvNlFOt) +| [Storage](https://github.com/cncf/wg-storage) | Ben Hindman | [2nd and 4th Wed every month at 8AM PT](https://zoom.us/my/cncfstoragewg) | [Youtube](https://www.youtube.com/playlist?list=PLj6h78yzYM2NoiNaLVZxr-ERc1ifKP7n6) All meetings are on the public CNCF calendar: https://goo.gl/eyutah From 93cb6c4b1578793550cb4bc92840201de62392ad Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 15 Jan 2018 17:50:34 -0600 Subject: [PATCH 20/27] Add Jan 16th 2018 meeting agenda https://goo.gl/5wBe3d --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 2adf9fe..e9e6576 100644 --- a/README.md +++ b/README.md @@ -167,3 +167,4 @@ If you're interested in presenting at a TOC call about your project, please open * [November 14th, 2017](https://goo.gl/vKbawR) * [December 5th, 2017](https://goo.gl/77pMFY) * [December 7th, 2017](https://goo.gl/Ugo7F9) +* [January 16th, 2018](https://goo.gl/5wBe3d) From a173ab79aefce4336ce0233127a6213708f078ff Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 16 Jan 2018 09:16:14 -0600 Subject: [PATCH 21/27] Add CoreDNS inception project review to schedule --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index e9e6576..fc51284 100644 --- a/README.md +++ b/README.md @@ -119,7 +119,9 @@ If you're interested in presenting at a TOC call about your project, please open * **December 5, 2017**: Rook, OpenOverlay * **December 7, 2017**: KubeCon/CloudNativeCon F2F * **January 16, 2018**: CSI/Storage WG Readout -* **Feb 6, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) +* **Feb 6, 2018**: TBD +* **Feb 20, 2018**: CoreDNS Inception Project Review +* **Mar 6, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) ## Meeting Minutes From ed8e73ba0cb59ce4dfa3025071421e2144f236fb Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 16 Jan 2018 11:42:25 -0600 Subject: [PATCH 22/27] Add NATS to feb 6 meeting --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fc51284..d1d1006 100644 --- a/README.md +++ b/README.md @@ -119,7 +119,7 @@ If you're interested in presenting at a TOC call about your project, please open * **December 5, 2017**: Rook, OpenOverlay * **December 7, 2017**: KubeCon/CloudNativeCon F2F * **January 16, 2018**: CSI/Storage WG Readout -* **Feb 6, 2018**: TBD +* **Feb 6, 2018**: NATS * **Feb 20, 2018**: CoreDNS Inception Project Review * **Mar 6, 2018**: (interested presenters contact cra@linuxfoundation.org or open up a github [issue](https://github.com/cncf/toc/issues) From 290dd6c7995bfcdaaa0140e0f984b0be8ae7034e Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Wed, 17 Jan 2018 13:32:56 -0500 Subject: [PATCH 23/27] Add website guidelines link --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index d1d1006..5eea1f4 100644 --- a/README.md +++ b/README.md @@ -84,6 +84,10 @@ Here is a link to a World Time Zone Converter here http://www.thetimezoneconvert [Notary](https://github.com/docker/notary)|Solomon Hykes|[6/20/17](https://goo.gl/6nmyDn)|[10/24/17](https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/)|Incubating [TUF](https://github.com/theupdateframework)|Solomon Hykes|[6/20/17](https://goo.gl/6nmyDn)|[10/24/17](https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/)|Incubating +## Website Guidelines + +CNCF has the following [guidelines](https://www.cncf.io/projects/website-guidelines/) for the websites of our projects. + ## Scheduled Community Presentations If you're interested in presenting at a TOC call about your project, please open a [github issue](https://github.com/cncf/toc/issues) with the request. We can schedule a maximum of two community presentations per TOC meeting. From 5a60c7c6be76c05f4a1af8dcf2a3a12a6e2d488d Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Sun, 21 Jan 2018 09:15:07 -0800 Subject: [PATCH 24/27] adding myself to contributors list --- CONTRIBUTORS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index a57251f..d593415 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -53,6 +53,7 @@ List below is the official list of TOC contributors, in alphabetical order: * Quinton Hoole, Huawei (quinton.hoole@huawei.com) * Randy Abernethy, RX-M LLC (randy.abernethy@rx-m.com) * Rick Spencer, Bitnami (rick@bitnamni.com) +* Sarah Allen, Google (sarahallen@google.com) * Timothy Chen, Hyperpilot (tim@hyperpilot.io) * Xu Wang, Hyper (xu@hyper.sh) * Yaron Haviv, iguazio (yaronh@iguaz.io) From 3dcc174ae3bd1deb85388131c7de4446abb514d1 Mon Sep 17 00:00:00 2001 From: Jeyappragash JJ Date: Tue, 23 Jan 2018 13:37:42 -0800 Subject: [PATCH 25/27] Adding myself(Jeyappragash JJ) to contributors.md I have been working on identity and access management open standards and protocols for the past year or so. Been involved with spiffee.io, started padme.io based on collaboration with few people in industry. Would love to help and see standard Security model emerge, that accelerates safe adoption of cloud native technologies in enterprises. --- CONTRIBUTORS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index d593415..363ba3d 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -59,3 +59,5 @@ List below is the official list of TOC contributors, in alphabetical order: * Yaron Haviv, iguazio (yaronh@iguaz.io) * Yong Tang, Infoblox (ytang@infoblox.com) * Yuri Shkuro, Uber (ys@uber.com) +* Jeyappragash JJ, Independent (pragashjj@gmail.com) + From e09b08b3b1f6dd849fa92dd03e1b3786b9b456f3 Mon Sep 17 00:00:00 2001 From: Jeyappragash JJ Date: Wed, 24 Jan 2018 06:57:50 -0800 Subject: [PATCH 26/27] Fixing the non-alphebetic insertion --- CONTRIBUTORS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index 363ba3d..dbbc261 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -38,6 +38,7 @@ List below is the official list of TOC contributors, in alphabetical order: * Gergely Csatari, Nokia (gergely.csatari@nokia.com) * Ghe Rivero, Independent (ghe.rivero@gmail.com) * Gou Rao, Portworx (gou@portworx.com) +* Jeyappragash JJ, Independent (pragashjj@gmail.com) * Jonghyuk Jong Choi, NCSoft (jongchoi@ncsoft.com) * Joseph Jacks, Independent (jacks.joe@gmail.com) * Josh Bernstein, Dell (Joshua.Bernstein@dell.com) @@ -59,5 +60,4 @@ List below is the official list of TOC contributors, in alphabetical order: * Yaron Haviv, iguazio (yaronh@iguaz.io) * Yong Tang, Infoblox (ytang@infoblox.com) * Yuri Shkuro, Uber (ys@uber.com) -* Jeyappragash JJ, Independent (pragashjj@gmail.com) From d249750de14730e1e1f5a857cb21c8c6591d6e4a Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Mon, 29 Jan 2018 10:27:00 -0600 Subject: [PATCH 27/27] Add rook as our 15th CNCF project https://rook.io/ --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 5eea1f4..8a34c19 100644 --- a/README.md +++ b/README.md @@ -83,6 +83,7 @@ Here is a link to a World Time Zone Converter here http://www.thetimezoneconvert [Jaeger](https://github.com/jaegertracing/jaeger)|Bryan Cantrill|[8/1/17](https://goo.gl/ehtgts)|[9/13/17](https://www.cncf.io/blog/2017/09/13/cncf-hosts-jaeger/)|Incubating [Notary](https://github.com/docker/notary)|Solomon Hykes|[6/20/17](https://goo.gl/6nmyDn)|[10/24/17](https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/)|Incubating [TUF](https://github.com/theupdateframework)|Solomon Hykes|[6/20/17](https://goo.gl/6nmyDn)|[10/24/17](https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/)|Incubating +[rook](https://github.com/rook)|Ben Hindman|[6/6/17](https://goo.gl/6nmyDn)|[1/29/18](https://www.cncf.io/blog/2018/01/29/cncf-host-rook-project-cloud-native-storage-capabilities)|Inception ## Website Guidelines