Date   

Re: Congrats and Questions!

Chris Aniszczyk
 

We plan on bringing this up in the next TOC meeting on Feb 5th (next Tuesday)


On Thu, Jan 31, 2019 at 3:53 PM Davanum Srinivas <davanum@...> wrote:
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



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: CNCF SIGs Proposal

Diane Mueller
 

Quinton, 

If you are referring to this one sentence:

"The TOC makes use of this input to act as an informed and effective executive board to select and promote appropriate CNCF projects and practices, and to disseminate high quality information to end users and the cloud-native community in general." as the section discussion the creation/instantiation/proposal process for new SIGs"

I'd like a bit more clarity. If someone from the community (outside of the TOC) wishes to propose a SIG, what it the process? Or is it just the purview of the TOC on know when a new SIG should be created - then that would be nice to have clarified further.

If there's another section of the document, that you feel clarifies this SIG instantiation/proposal process, please point me in the right direction. I'm just not finding it.

Thanks for your help,

Diane Mueller
@openshiftcommon

On Thu, Jan 31, 2019 at 6:16 AM Quinton Hoole <quinton.hoole@...> wrote:
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

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:
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

can you put this link into the main doc as a comment?

On Tue, Jan 15, 2019 at 3:57 PM Alex Chircop <alex.chircop@...> wrote:

Hi Alexis,


Following our initial discussion in Seattle, Quinton and I had a discussion on this.   I captured the notes and applied them to the operating model.   I decided to make a copy of the doc and apply the changes to operating model section only - the current doc is hard to process due to the number of comments.


Here is the amended operating model content: https://docs.google.com/document/d/1ySri5jVrPaJjTJ_tZnDzcc4Xmcm4uKoUrHT6lVO6Pcw/edit#heading=h.6cl6hmsbz9fv


Kind Regards,

Alex





From: Alexis Richardson <alexis@...>
Sent: 09 January 2019 19:36
To: Erin Boyd; Sarah Allen
Cc: Bryan Cantrill; Chris Aniszczyk; Quinton Hoole; Alex Chircop; Matt Farina
Subject: CNCF TOC SIGs Doc
 
hi all

happy 2019!

how's this doc looking?  I daren't look.  can we show the toc an update next week?

a



On Mon, Dec 10, 2018 at 5:35 AM Alexis Richardson <alexis@...> wrote:
+sarah

On Fri, 7 Dec 2018, 13:35 Erin Boyd, <eboyd@...> wrote:
Sounds good.
Please feel free to catch me on Slack.

Erin


On Wed, Dec 5, 2018 at 11:18 PM Alexis Richardson <alexis@...> wrote:
Thank you Erin.  Let's try and sync 1-1 during the week 

On Thu, 6 Dec 2018, 00:42 Erin Boyd, <eboyd@...> wrote:
HI Alexis,
I think I am speaking on a panel at this time.
I can collaborate in the document.
Sorry about that.
Thanks,
Erin


On Tue, Dec 4, 2018 at 11:46 AM Alexis Richardson <alexis@...> wrote:

CNCF TOC meeting re SIGs Doc

meeting to discuss the Categories and SIGs doc
identify and divide up work tasks to clean up draft doc.
eg: we agree a new section plan and each take one section? or something
When
Mon Dec 10, 2018 3:30pm – 4:10pm Mountain Time - Denver
Where
lobby of the Sheraton Grand Seattle (map)
Joining info
meet.google.com/hud-jxti-yvh
Or dial: +1 929-299-3513  PIN: 706587657#
Calendar
eboyd@...
Who
Alexis Richardson - organizer
Matt Farina
Chris Aniszczyk

Going (eboyd@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this email at the account eboyd@... because you are subscribed for invitations on calendar eboyd@....

To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.



--
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



--
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


Congrats and Questions!

Davanum Srinivas
 

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

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:
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

can you put this link into the main doc as a comment?

On Tue, Jan 15, 2019 at 3:57 PM Alex Chircop <alex.chircop@...> wrote:

Hi Alexis,


Following our initial discussion in Seattle, Quinton and I had a discussion on this.   I captured the notes and applied them to the operating model.   I decided to make a copy of the doc and apply the changes to operating model section only - the current doc is hard to process due to the number of comments.


Here is the amended operating model content: https://docs.google.com/document/d/1ySri5jVrPaJjTJ_tZnDzcc4Xmcm4uKoUrHT6lVO6Pcw/edit#heading=h.6cl6hmsbz9fv


Kind Regards,

Alex





From: Alexis Richardson <alexis@...>
Sent: 09 January 2019 19:36
To: Erin Boyd; Sarah Allen
Cc: Bryan Cantrill; Chris Aniszczyk; Quinton Hoole; Alex Chircop; Matt Farina
Subject: CNCF TOC SIGs Doc
 
hi all

happy 2019!

how's this doc looking?  I daren't look.  can we show the toc an update next week?

a



On Mon, Dec 10, 2018 at 5:35 AM Alexis Richardson <alexis@...> wrote:
+sarah

On Fri, 7 Dec 2018, 13:35 Erin Boyd, <eboyd@...> wrote:
Sounds good.
Please feel free to catch me on Slack.

Erin


On Wed, Dec 5, 2018 at 11:18 PM Alexis Richardson <alexis@...> wrote:
Thank you Erin.  Let's try and sync 1-1 during the week 

On Thu, 6 Dec 2018, 00:42 Erin Boyd, <eboyd@...> wrote:
HI Alexis,
I think I am speaking on a panel at this time.
I can collaborate in the document.
Sorry about that.
Thanks,
Erin


On Tue, Dec 4, 2018 at 11:46 AM Alexis Richardson <alexis@...> wrote:

CNCF TOC meeting re SIGs Doc

meeting to discuss the Categories and SIGs doc
identify and divide up work tasks to clean up draft doc.
eg: we agree a new section plan and each take one section? or something
When
Mon Dec 10, 2018 3:30pm – 4:10pm Mountain Time - Denver
Where
lobby of the Sheraton Grand Seattle (map)
Joining info
meet.google.com/hud-jxti-yvh
Or dial: +1 929-299-3513  PIN: 706587657#
Calendar
eboyd@...
Who
Alexis Richardson - organizer
Matt Farina
Chris Aniszczyk

Going (eboyd@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this email at the account eboyd@... because you are subscribed for invitations on calendar eboyd@....

To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.



--
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: CNCF SIGs Proposal

Diane Mueller
 

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:
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

can you put this link into the main doc as a comment?

On Tue, Jan 15, 2019 at 3:57 PM Alex Chircop <alex.chircop@...> wrote:

Hi Alexis,


Following our initial discussion in Seattle, Quinton and I had a discussion on this.   I captured the notes and applied them to the operating model.   I decided to make a copy of the doc and apply the changes to operating model section only - the current doc is hard to process due to the number of comments.


Here is the amended operating model content: https://docs.google.com/document/d/1ySri5jVrPaJjTJ_tZnDzcc4Xmcm4uKoUrHT6lVO6Pcw/edit#heading=h.6cl6hmsbz9fv


Kind Regards,

Alex





From: Alexis Richardson <alexis@...>
Sent: 09 January 2019 19:36
To: Erin Boyd; Sarah Allen
Cc: Bryan Cantrill; Chris Aniszczyk; Quinton Hoole; Alex Chircop; Matt Farina
Subject: CNCF TOC SIGs Doc
 
hi all

happy 2019!

how's this doc looking?  I daren't look.  can we show the toc an update next week?

a



On Mon, Dec 10, 2018 at 5:35 AM Alexis Richardson <alexis@...> wrote:
+sarah

On Fri, 7 Dec 2018, 13:35 Erin Boyd, <eboyd@...> wrote:
Sounds good.
Please feel free to catch me on Slack.

Erin


On Wed, Dec 5, 2018 at 11:18 PM Alexis Richardson <alexis@...> wrote:
Thank you Erin.  Let's try and sync 1-1 during the week 

On Thu, 6 Dec 2018, 00:42 Erin Boyd, <eboyd@...> wrote:
HI Alexis,
I think I am speaking on a panel at this time.
I can collaborate in the document.
Sorry about that.
Thanks,
Erin


On Tue, Dec 4, 2018 at 11:46 AM Alexis Richardson <alexis@...> wrote:

CNCF TOC meeting re SIGs Doc

meeting to discuss the Categories and SIGs doc
identify and divide up work tasks to clean up draft doc.
eg: we agree a new section plan and each take one section? or something
When
Mon Dec 10, 2018 3:30pm – 4:10pm Mountain Time - Denver
Where
lobby of the Sheraton Grand Seattle (map)
Joining info
meet.google.com/hud-jxti-yvh
Or dial: +1 929-299-3513  PIN: 706587657#
Calendar
eboyd@...
Who
Alexis Richardson - organizer
Matt Farina
Chris Aniszczyk

Going (eboyd@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this email at the account eboyd@... because you are subscribed for invitations on calendar eboyd@....

To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.



--
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 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.

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

can you put this link into the main doc as a comment?

On Tue, Jan 15, 2019 at 3:57 PM Alex Chircop <alex.chircop@...> wrote:

Hi Alexis,


Following our initial discussion in Seattle, Quinton and I had a discussion on this.   I captured the notes and applied them to the operating model.   I decided to make a copy of the doc and apply the changes to operating model section only - the current doc is hard to process due to the number of comments.


Here is the amended operating model content: https://docs.google.com/document/d/1ySri5jVrPaJjTJ_tZnDzcc4Xmcm4uKoUrHT6lVO6Pcw/edit#heading=h.6cl6hmsbz9fv


Kind Regards,

Alex





From: Alexis Richardson <alexis@...>
Sent: 09 January 2019 19:36
To: Erin Boyd; Sarah Allen
Cc: Bryan Cantrill; Chris Aniszczyk; Quinton Hoole; Alex Chircop; Matt Farina
Subject: CNCF TOC SIGs Doc
 
hi all

happy 2019!

how's this doc looking?  I daren't look.  can we show the toc an update next week?

a



On Mon, Dec 10, 2018 at 5:35 AM Alexis Richardson <alexis@...> wrote:
+sarah

On Fri, 7 Dec 2018, 13:35 Erin Boyd, <eboyd@...> wrote:
Sounds good.
Please feel free to catch me on Slack.

Erin


On Wed, Dec 5, 2018 at 11:18 PM Alexis Richardson <alexis@...> wrote:
Thank you Erin.  Let's try and sync 1-1 during the week 

On Thu, 6 Dec 2018, 00:42 Erin Boyd, <eboyd@...> wrote:
HI Alexis,
I think I am speaking on a panel at this time.
I can collaborate in the document.
Sorry about that.
Thanks,
Erin


On Tue, Dec 4, 2018 at 11:46 AM Alexis Richardson <alexis@...> wrote:

CNCF TOC meeting re SIGs Doc

meeting to discuss the Categories and SIGs doc
identify and divide up work tasks to clean up draft doc.
eg: we agree a new section plan and each take one section? or something
When
Mon Dec 10, 2018 3:30pm – 4:10pm Mountain Time - Denver
Where
lobby of the Sheraton Grand Seattle (map)
Joining info
meet.google.com/hud-jxti-yvh
Or dial: +1 929-299-3513  PIN: 706587657#
Calendar
eboyd@...
Who
Alexis Richardson - organizer
Matt Farina
Chris Aniszczyk

Going (eboyd@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this email at the account eboyd@... because you are subscribed for invitations on calendar eboyd@....

To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


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:
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

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:
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

Welcome new TOC members!

We have several projects asking for graduation reviews: Fluentd, containerd, TUF, NATS, and Jaeger.

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?

I've recently heard from a user that they didn't think most software in the ecosystem was usable in production due to lack of scalability, reliability, security, and other issues. I also heard from a security engineer that they wouldn't trust most open source due to lack of rigorous review processes, especially of dependencies. Within Kubernetes, we've found that CVEs don't appear to be tracked for Golang libraries.

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?


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

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:
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

Welcome new TOC members!

We have several projects asking for graduation reviews: Fluentd, containerd, TUF, NATS, and Jaeger.

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?

I've recently heard from a user that they didn't think most software in the ecosystem was usable in production due to lack of scalability, reliability, security, and other issues. I also heard from a security engineer that they wouldn't trust most open source due to lack of rigorous review processes, especially of dependencies. Within Kubernetes, we've found that CVEs don't appear to be tracked for Golang libraries.

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?


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:
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

Welcome new TOC members!

We have several projects asking for graduation reviews: Fluentd, containerd, TUF, NATS, and Jaeger.

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?

I've recently heard from a user that they didn't think most software in the ecosystem was usable in production due to lack of scalability, reliability, security, and other issues. I also heard from a security engineer that they wouldn't trust most open source due to lack of rigorous review processes, especially of dependencies. Within Kubernetes, we've found that CVEs don't appear to be tracked for Golang libraries.

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?


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

Welcome new TOC members!

We have several projects asking for graduation reviews: Fluentd, containerd, TUF, NATS, and Jaeger.

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?

I've recently heard from a user that they didn't think most software in the ecosystem was usable in production due to lack of scalability, reliability, security, and other issues. I also heard from a security engineer that they wouldn't trust most open source due to lack of rigorous review processes, especially of dependencies. Within Kubernetes, we've found that CVEs don't appear to be tracked for Golang libraries.

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?


revisiting our graduation criteria and process

Brian Grant
 

Welcome new TOC members!

We have several projects asking for graduation reviews: Fluentd, containerd, TUF, NATS, and Jaeger.

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?

I've recently heard from a user that they didn't think most software in the ecosystem was usable in production due to lack of scalability, reliability, security, and other issues. I also heard from a security engineer that they wouldn't trust most open source due to lack of rigorous review processes, especially of dependencies. Within Kubernetes, we've found that CVEs don't appear to be tracked for Golang libraries.

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

Chris Aniszczyk
 

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)

Chris Aniszczyk
 

The vote for CoreDNS moving to the graduation maturity level has been approved:

https://github.com/cncf/toc/pull/172
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:
Golfen Guo: https://lists.cncf.io/g/cncf-toc/message/2794
Roman 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:
CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.
* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md

- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors

- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

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



--
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:
CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.
* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md

- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors

- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

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

--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Follow Us Twitter LinkedIn Facebook YouTube
 


Re: [VOTE] CoreDNS moving to graduation

Ken Owens
 

+1 Binding

On Tue, Jan 15, 2019 at 11:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.
* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md

- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors

- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

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

郑淮城 <huaicheng.zheng@...>
 

+1 non-binding

 

郑淮城
星环信息科技(上海)有限公司
15216615728
徐汇区虹漕路88号越虹广场B11-12

 

 

发件人: <cncf-toc@...> 代表 "Wilson, Dan" <dan.wilson01@...>
日期: 2019119 星期六 上午5:03
收件人: Chris Aniszczyk <caniszczyk@...>, CNCF TOC <cncf-toc@...>
主题: Re: [cncf-toc] [VOTE] CoreDNS moving to graduation

 

+1 non-binding

 

 

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Tuesday, January 15, 2019 at 9:47 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] CoreDNS moving to graduation

 

CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

 

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

 

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.

* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md


- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors


- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

 

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

Zhang Lei
 

+1 NB

We use & like CoreDNS!

On Fri, Jan 18, 2019 at 12:40 PM Benjamin Porter <bporter@...> wrote:
+1 non-binding

On Fri, Jan 18, 2019 at 11:34 AM Cathy zhang <cathy.h.zhang@...> wrote:

+1 non-binding

 

Cathy

 

From: cncf-toc@... [mailto:cncf-toc@...] On Behalf Of Christian Posta
Sent: Friday, January 18, 2019 8:54 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] CoreDNS moving to graduation

 

+1 non binding

 

On Tue, Jan 15, 2019 at 10:47 AM Chris Aniszczyk <caniszczyk@...> wrote:

CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

 

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

 

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.

* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md


- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors


- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

 

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


 

--

Christian Posta

twitter: @christianposta

 

 

 


Re: [VOTE] CoreDNS moving to graduation

Ayrat Khayretdinov <akhayretdinov@...>
 

+1 (non-binding)


On Tue, Jan 15, 2019, 12:47 Chris Aniszczyk <caniszczyk@... wrote:
CoreDNS has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/172

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/ 

The CoreDNS community believes it has fulfilled all the graduation criteria:

- Document that it is being used successfully in production by at least three independent end users:

* SoundCloud uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* Infoblox uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS.
* Admiral uses CoreDNS to handle geographic DNS requests for our public-facing microservices.
* Qunar uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes.
* Tradeshift uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* AdGuard uses CoreDNS in AdGuard Home and, therefore, in production public AdGuard DNS servers.
* Bose, Zalando, Yandex, Hellofresh, Sodimac, Kismia and many others use CoreDNS for their production's Kubernetes Cluster: https://github.com/coredns/coredns/blob/master/ADOPTERS.md

- Have a healthy number of committers and at least two from different organizations: 16+ maintainers: Google, Infoblox, Independent(s) - More than 100+ contributors - https://github.com/coredns/coredns/blob/master/OWNERS and https://github.com/coredns/coredns/graphs/contributors

- Demonstrate a substantial ongoing flow of commits and merged contributions: 10+ releases since becoming an incubating project and average about 150 PRs merged / quarter: https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=CoreDNS

- Have achieved a CII badge: https://bestpractices.coreinfrastructure.org/projects/1250

- Define a governance model: https://github.com/coredns/coredns/blob/master/GOVERNANCE.md

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/172

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

4901 - 4920 of 7724