|
Congrats and Questions!
Hi, Congrats to all the folks on the brand-new TOC! :) I spotted a few concerns in the community around the TOC election and wanted to see if anyone had thoughts about them. One was around diversity and the other one was the electorate that gets to vote in the TOC election. Please see examples [1][2][3][4]. Thanks, Dims
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: CNCF SIGs Proposal
Quinton Hoole
Thanks Diane
I think that’s adequately covered in the doc - the TOC creates and approves SIG’s. If anyone believes we need to create more SIG’s, they should, by implication, ask the TOC to do that. The current intention is to keep the number of SIGs relatively small,
at least initially, and make sure they’re all highly effective before expanding the number of SIG's.
Q
From: <cncf-toc@...> on behalf of Diane Mueller-Klingspor <dmueller@...>
Date: Thursday, January 31, 2019 at 05:27 To: Quinton Hoole <quinton.hoole@...> Cc: "cncf-toc@..." <cncf-toc@...>, Erin Boyd <eboyd@...>, Sarah Allen <sarahallen@...>, Bryan Cantrill <bryan@...>, Chris Aniszczyk <caniszczyk@...>, Matt Farina <matt.farina@...>, Alex Chircop <alex.chircop@...>, Alexis Richardson <alexis@...> Subject: Re: [cncf-toc] CNCF SIGs Proposal
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: CNCF SIGs Proposal
Quinton et al, Would it be possible to ask for a section in the Operator Model on how one goes about proposing a new SIG and the process for getting it approved? (or if there is documentation on this topic elsewhere, reference/link to it in an appendix)? Kind Regards, Diane Mueller Director, Community Development Red Hat @openshiftcommon
On Wed, Jan 30, 2019 at 10:47 PM Quinton Hoole <quinton.hoole@...> wrote:
--
Kind Regards, Diane Mueller Director, Community Development Red Hat OpenShift @openshiftcommons We have more in Common than you know, learn more at http://commons.openshift.org
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: revisiting our graduation criteria and process
Dan Kohn <dan@...>
On Wed, Jan 30, 2019 at 11:22 PM Matt Klein <mattklein123@...> wrote:
I recruited David Wheeler to create the Best Practices Badge for CII and worked with him to create both the passing and higher milestone levels and build the BadgeApp. David is open to making adjustments to the criteria, although there are obviously issues around backward compatibility for existing badge holders. We're waiting for David to confirm that he can present at the 2/19 TOC meeting if you'd like to hear from him. We've also arranged for him to attend OSLS and I would encourage you to meet with him there. -- Dan Kohn <dan@...> Executive Director, Cloud Native Computing Foundation https://www.cncf.io +1-415-233-1000 https://www.dankohn.com
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
CNCF SIGs Proposal
Quinton Hoole
Greetings to the new TOC
Late last year Alexis kicked off a public discussion regarding forming CNCF SIG’s (initially referred to as Categories). Since then a few of us have collaborated on soliciting further input, addressing all the comments, and producing a finalish proposal
for consideration by the TOC.
Please give it a read and we can decide how to proceed at the next meeting this Tue, Feb 5
Q
From: Alexis Richardson <alexis@...>
Date: Tuesday, January 15, 2019 at 07:58 To: Alex Chircop <alex.chircop@...> Cc: Erin Boyd <eboyd@...>, Sarah Allen <sarahallen@...>, Bryan Cantrill <bryan@...>, Chris Aniszczyk <caniszczyk@...>, Quinton Hoole <quinton.hoole@...>, Matt Farina <matt.farina@...> Subject: Re: CNCF TOC SIGs Doc
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: revisiting our graduation criteria and process
Matt Klein
I would encourage you all to take a walk through a CII Best Practises declaration if you haven’t already done so – it’s reasonably good and comprehensive, IMO. I was pleasantly surprised. I agree it's a great start. Personally I think we should come up with a custom variant the tweaks some of the values and focuses on some key common elements. As for not requiring quantification of performance or scalability as a graduation criterion, I hear your concern, but I think even a limited form of that (e.g. “publish repeatable performance and scalability results for one or more representative configurations and deployment targets”) would be vastly better than the nothing that we have now. I think if we want to go down this road (which I still don't recommend), it would require CNCF funding for contractors to setup a repeatable performance profiling framework, hook it up to CI, etc. This is an extremely non-trivial undertaking that can take months of people-effort to do correctly. On Wed, Jan 30, 2019 at 9:13 PM Quinton Hoole <quinton.hoole@...> wrote:
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: revisiting our graduation criteria and process
Quinton Hoole
Matt, most of the things you mention are fairly well covered by the CII Best Practices program, a basic version of which is currently a CNCF graduation requirement, as Brian detailed below.
I would encourage you all to take a walk through a CII Best Practises declaration if you haven’t already done so – it’s reasonably good and comprehensive, IMO. I was pleasantly surprised.
As for not requiring quantification of performance or scalability as a graduation criterion, I hear your concern, but I think even a limited form of that (e.g. “publish repeatable performance and scalability results for one or more representative configurations
and deployment targets”) would be vastly better than the nothing that we have now.
Q
From: Matt Klein <mattklein123@...>
Date: Wednesday, January 30, 2019 at 19:09 To: Quinton Hoole <quinton.hoole@...> Cc: "briangrant@..." <briangrant@...>, cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] revisiting our graduation criteria and process
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: revisiting our graduation criteria and process
Matt Klein
I would be weary of requiring quantification of scalability or performance as a graduation project requirement, mainly because in my experience it's virtually impossible to accurately do so given the number of different configurations and deployment targets (on prem, IaaS, different HW types, etc.) that end users end up deploying the software to. I would much rather see us get crisper around the underlying attributes that we care about and be more clear about the requirements (not leave so many things up to the "judgement" of the TOC). These are attributes like security auditing and CVE procedures, CI, test coverage % and type of test coverage (unit tests, integration tests, fuzz tests, etc.), code review procedures, stability of the master branch, PR review/merge throughput, number of end users, scale of end users, number of full-time maintainers, number of maintainer orgs, governance and dispute resolution model, etc. I have lots of opinions on how I would personally quantify some of the things I listed above as a graduation requirement, but it's probably more prudent to start with a list of things that we care to quantify.
On Wed, Jan 30, 2019 at 2:20 PM Quinton Hoole <quinton.hoole@...> wrote:
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: revisiting our graduation criteria and process
Quinton Hoole
I think “production ready” has a lot to do with known, accurate and well-documented limitations, as opposed to no limitations at all, or vague claims, or an absolute set of metrics that need to be met (e.g. around scalability) for all projects.
As a contrived concrete example, a project that reliably and demonstrably scales to say 100 nodes, and clearly publishes data supporting that fact, might be perfectly production-ready for a user that has no intention of ever exceeding that scale for their
use of that project (and vastly more appealing than another project that makes vague and exaggerated claims about scalability, which turn out not to be true in practical use cases).
For that reason I like the CII model, which is more about clearing articulating what’s there, and what’s not, than it is about checking off a bunch of “must-have" checkboxes. Clearly there will be at least a few “must-have” checkboxes, but I think there
will be vastly more “do we understand and clearly document this limitation” type items. And then the overall question around whether, given the known limitations, a project is useful for a sufficiently significant set of production use cases.
Until now, we have tended to use the number and size of claimed or actual production use cases as an approximation of the answer to the aforementioned question.
Q
From: <cncf-toc@...> on behalf of "Brian Grant via Lists.Cncf.Io" <briangrant=google.com@...>
Reply-To: "briangrant@..." <briangrant@...> Date: Wednesday, January 30, 2019 at 12:34 To: cncf-toc <cncf-toc@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: [cncf-toc] revisiting our graduation criteria and process
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
revisiting our graduation criteria and process
Brian Grant
Welcome new TOC members! I didn't participate in some recent project graduation votes because I didn't feel I had adequate information to make a decision. In one case, due diligence that had been performed hadn't been documented or presented. In another, the content of the application (basically a checklist and a list of users) didn't seem sufficient, despite nominally meeting our criteria. Our current criteria are here: There is a proposal to add a security audit to the requirements, which is a good step: But I think we need to start with revisiting what we want graduation to mean to users, and then ensure that the criteria ensure those attributes. I should also add that whatever criteria we come up with, we should ensure the CNCF helps projects meet those criteria. Our criteria imply that we want users to be able to use the projects in relatively critical (probably should be defined) so-called "production" use cases. How should we ensure that is the case? Does wide usage of a project suggest that these issues have been overcome? That's not clear to me, particularly since Kubernetes itself needs plenty of improvement. I've started to look more stringent CII criteria: One possible approach is for us to require the gold standard, and then work with CII to ensure it covers some of the relevant criteria, or to define an even more rigorous "platinum" level. We also might want a scalability standard. Is 100 nodes/instances/something sufficiently scalable? 1000? I also assume we want users to value the CNCF graduated status. As is, it's hard for an external observer to tell whether we're a rubber stamp or made a well informed decision. Perhaps it's worth providing a rationale/justification statement rather than just "+1". Thoughts?
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
FYI: TOC Election Results 2019
Hey all, here are the results for the GB-selected TOC seats: https://www.cncf.io/blog/2019/01/29/new-year-new-toc/ https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=6&id=E_c93ca3b3af0efa64&rkey=2a4b133473e1255c&algorithm=runoff The top 6 GB-selected candidates have confirmed that they will serve on the TOC: Alexis Richardson (Weaveworks) Brendan Burns (Microsoft) Xiang Li (Alibaba) Joe Beda (VMWare) Kelsey Hightower (Google) Matt Klein (Lyft) The CNCF End User seat goes to Intuit and will be served by Jeff Brewer. We want to personally to thank the outgoing TOC members who were with CNCF since its inception and helped the organization become what it is today. Existing TOC members will be listed as an emeritus member of the TOC (https://github.com/cncf/toc/blob/master/EMERITUS.md) and will always have an honored position with CNCF and my gratitude. A few of important things to note, there is also an upcoming TOC-selected seat that becomes open on 3/17/2019 (Quinton) that the TOC will have to select by then. There are also some logistics around staggered terms (split 1yr/2yr terms) for the newly elected TOC members but we will take care of that by the next TOC meeting. There is also a be a TOC chair election. Thanks everyone, we will do a session at the next TOC meeting on Feb 5th giving new and the newly emeritus TOC members a chance to speak. Chris Aniszczyk (@cra) | +1-512-961-6719
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
[RESULT] CoreDNS moving to graduation (PASSED)
The vote for CoreDNS moving to the graduation maturity level has been approved: https://www.cncf.io/announcement/2019/01/24/coredns-graduation/ +1 binding TOC votes (7/9): Alexis: https://lists.cncf.io/g/cncf-toc/message/2776 Quinton: https://lists.cncf.io/g/cncf-toc/message/2786 Jon: https://lists.cncf.io/g/cncf-toc/message/2788 Camille: https://lists.cncf.io/g/cncf-toc/message/2799 Bryan: https://lists.cncf.io/g/cncf-toc/message/2800 Ken: https://lists.cncf.io/g/cncf-toc/message/2810 Ben: https://lists.cncf.io/g/cncf-toc/message/2811 +1 non-binding community votes: John Belamaric: https://lists.cncf.io/g/cncf-toc/message/2763 Ihor Dvoretskyi: https://lists.cncf.io/g/cncf-toc/message/2764 Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/2765 Sonya Kopytev: https://lists.cncf.io/g/cncf-toc/message/2766 Ruben Orduz: https://lists.cncf.io/g/cncf-toc/message/2767 Randy Abernathy: https://lists.cncf.io/g/cncf-toc/message/2768 Lee Calcote: https://lists.cncf.io/g/cncf-toc/message/2769 Doug Davis: https://lists.cncf.io/g/cncf-toc/message/2770 Bob Killeen: https://lists.cncf.io/g/cncf-toc/message/2772 Igor Mameshin: https://lists.cncf.io/g/cncf-toc/message/2773 Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/2774 Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/2775 Yassine Tijani: https://lists.cncf.io/g/cncf-toc/message/2778 Nicolas Frankel: https://lists.cncf.io/g/cncf-toc/message/2779 Christian Jantz: https://lists.cncf.io/g/cncf-toc/message/2780 Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/2781 Julien Senon: https://lists.cncf.io/g/cncf-toc/message/2782 Vlad Voskoboynikov: https://lists.cncf.io/g/cncf-toc/message/2783 Justin Garrison: https://lists.cncf.io/g/cncf-toc/message/2784 Justin Cappos: https://lists.cncf.io/g/cncf-toc/message/2785 Michael Huasenblas: https://lists.cncf.io/g/cncf-toc/message/2787 Jimmy Song: https://lists.cncf.io/g/cncf-toc/message/2791 Phil Estes: https://lists.cncf.io/g/cncf-toc/message/2792 Michael Payne: https://lists.cncf.io/g/cncf-toc/message/2793 Golfen Guo: https://lists.cncf.io/g/cncf-toc/message/2794Roman Chepurnyi: https://lists.cncf.io/g/cncf-toc/message/2795 徐翔轩: https://lists.cncf.io/g/cncf-toc/message/2796 Heng Du: https://lists.cncf.io/g/cncf-toc/message/2797 Mark Peek: https://lists.cncf.io/g/cncf-toc/message/2801 Erin Boyd: https://lists.cncf.io/g/cncf-toc/message/2802 Christian Posta: https://lists.cncf.io/g/cncf-toc/message/2803 Cathy Zhang: https://lists.cncf.io/g/cncf-toc/message/2804 Benjamin Porter: https://lists.cncf.io/g/cncf-toc/message/2805 Dan Wilson: https://lists.cncf.io/g/cncf-toc/message/2806 Ayrat Khayretdinov: https://lists.cncf.io/g/cncf-toc/message/2807 Zhang Lei: https://lists.cncf.io/g/cncf-toc/message/2808 郑淮城: https://lists.cncf.io/g/cncf-toc/message/2809 Christopher Liljenstolpe: https://lists.cncf.io/g/cncf-toc/message/2812 Thanks all for voting! Chris Aniszczyk (@cra) | +1-512-961-6719
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
Christopher LILJENSTOLPE <cdl@...>
+1 non binding
On Tue, Jan 15, 2019 at 9:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
--
Christopher LILJENSTOLPE Co-Founder & CTO, Solutions Tigera cdl@... | @liljenstolpe | @liljenstolpe Follow us: Blog | Twitter | LinkedIn Zero Trust Network Security & Continuous Compliance for Modern Applications
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
Benjamin Hindman
+1 binding
On Tue, Jan 15, 2019 at 12:47 PM Chris Aniszczyk <caniszczyk@...> wrote:
--
Benjamin Hindman Founder of Mesosphere and Co-Creator of Apache Mesos Follow us on Twitter: @mesosphere
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
Ken Owens
+1 Binding
On Tue, Jan 15, 2019 at 11:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
郑淮城 <huaicheng.zheng@...>
+1 non-binding
郑淮城
发件人: <cncf-toc@...> 代表 "Wilson, Dan" <dan.wilson01@...>
+1 non-binding
From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
CoreDNS has requested to move to the graduation maturity level:
The CoreDNS community was one of earlier projects that joined CNCF at the inception/sandbox level on March 2017 (sponsored by Jon Boulle) and moved to the incubation maturity level on Feb 2018. As of Kubernetes v1.13, CoreDNS is the default DNS server (https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/) and the community went under an external security audit last year sponsored by CNCF: https://coredns.io/2018/03/15/cure53-security-assessment/
* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second. * Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250
Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
+1 NB We use & like CoreDNS!
On Fri, Jan 18, 2019 at 12:40 PM Benjamin Porter <bporter@...> wrote:
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
Ayrat Khayretdinov <akhayretdinov@...>
+1 (non-binding)
On Tue, Jan 15, 2019, 12:47 Chris Aniszczyk <caniszczyk@... wrote:
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
Wilson, Dan <dan.wilson01@...>
+1 non-binding
From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
CoreDNS has requested to move to the graduation maturity level:
The CoreDNS community was one of earlier projects that joined CNCF at the inception/sandbox level on March 2017 (sponsored by Jon Boulle) and moved to the incubation maturity level on Feb 2018. As of Kubernetes v1.13, CoreDNS is the default
DNS server (https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/) and the community went under an external security audit last year sponsored by
CNCF: https://coredns.io/2018/03/15/cure53-security-assessment/
* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second. * Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
- Have achieved a CII badge:
https://bestpractices.coreinfrastructure.org/projects/1250
Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||
|
Re: [VOTE] CoreDNS moving to graduation
bporter@...
+1 non-binding
On Fri, Jan 18, 2019 at 11:34 AM Cathy zhang <cathy.h.zhang@...> wrote:
|
|||||||||||||||||||||||||||||
|
|
