cncf-toc@lists.cncf.io

Re: "Steering committee" discussion

alexis richardson

#5343

"Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community"

This mostly does not happen. Although due to some bad actors, it can. Mostly projects are a handful of people on a mission, struggling to make it work, in the face of massive demands and uncertainty.

"What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality?"

The SC model could generate

* quarterly roadmap

* contributor ladder

* contingency plan

a

Show quoted text

On Tue, Sep 29, 2020 at 6:48 PM Bob Wise (AWS) via lists.cncf.io <wisebob=amazon.com@...> wrote:

What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.

Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.

-bw

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, September 29, 2020 at 10:44 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns:

1. longevity of the project (in the event that a vendor is acquired or goes out of business)

2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)

We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points

As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap

As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.

Many thanks everyone for your comments and feedback around these ideas!

Liz

Re: "Steering committee" discussion

Bob Wise (AWS)

#5342

What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.

Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.

-bw

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, September 29, 2020 at 10:44 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns:

1. longevity of the project (in the event that a vendor is acquired or goes out of business)

2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)

We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points

As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap
As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.

Many thanks everyone for your comments and feedback around these ideas!

Liz

Re: "Steering committee" discussion

alexis richardson

#5341

I wish to note that it was @cra's idea.  I just wrote about it and
then talked about it a lot.

Show quoted text

On Tue, Sep 29, 2020 at 6:43 PM Liz Rice <liz@...> wrote:

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns:
1. longevity of the project (in the event that a vendor is acquired or goes out of business)
2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)
We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points

As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap
As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.

Many thanks everyone for your comments and feedback around these ideas!

Liz

"Steering committee" discussion

Liz Rice

#5340

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns:

1. longevity of the project (in the event that a vendor is acquired or goes out of business)

2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)

We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points

As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap
As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.

Many thanks everyone for your comments and feedback around these ideas!

Liz

Re: FOSS Governance Library

Chris Aniszczyk

#5339

This is great!

Here's another solid resource that we put together last year that covers the "openness of projects" along with some criteria to look at.

Show quoted text

On Tue, Sep 29, 2020 at 11:36 AM Matt Farina <matt@...> wrote:

Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt

--

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

PDF

lf_determiningopenness_ebook_071519.pdf

FOSS Governance Library

Matt Farina

#5338

Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt

Re: OPA to graduation

Andrés Vega

#5337

Working in synchronicity from the authentication problem space adjacent to authorization, it has been fascinating to watch OPA evolve and grow in both adoption and maturity.

In every SPIFFE and SPIRE conversation, OPA always surfaces as the best architectural fit for a comprehensive identity and authorization solution. While there is a learning curve to Rego, people do manage to wrap their heads around it as it pays dividends in return.

As Joe, I'd like to see overtime further standardization of the APIs.

+1 NB

Andres

Agenda for TOC meeting for 9/29

Amye Scavarda Perrin

#5336

Hi all,

We'll be meeting tomorrow at 8am Pacific, discussing graduation requirements around maintainer diversity.

Presentation: https://docs.google.com/presentation/d/1Y0hfqLyxt1D0ThmPaQLRsejA8-8xlG5_yy2rGA1-fS4/edit#slide=id.g25ca91f87f_0_168

Agenda: https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit#

Thanks!

-- amye

--

Amye Scavarda Perrin | Program Manager | amye@...

Re: OPA to graduation

alexis richardson

#5335

Something something "doomed to reinvent lisp"...

+1, nb

Show quoted text

On Mon, 28 Sep 2020, 20:14 Joe Beda, <jbeda@...> wrote:

+1 NB

Agree with Gareth that there is no silver bullet here. Just like programming languages there are preferences and different needs and no one size fits all solution.

That being said, I think that OPA clearly hits a sweet spot and has a growing community. And the CNCF is welcoming to ~competing projects so graduating OPA doesn’t mean that other alternatives can’t also be supported and part of the CNCF umbrella.

One thing that I’d, personally, like to see is more standardization around the interfaces to these type of systems. Is it possible to replace OPA with another similar system and not have to retool the APIs to the policy engine? Would be interesting to standardize around some other interfaces to OPA too like the way that side-channel data is specified/presented and the way that decision information is surfaced back up to external monitoring/logging systems. (I’ve passed this on to the OPA folks so it should be a surprise to them.)

Joe

From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikehadlow.blogspot.com%2F2012%2F05%2Fconfiguration-complexity-clock.html&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&reserved=0

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcruise-automation%2Fk-rail&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&reserved=0) and Kyverno
(using YAML for authoring https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&reserved=0)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.openpolicyagent.org%2F&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&reserved=0. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgithub%2Flinguist%2Fissues%2F4219&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&reserved=0 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%259C%2593%26type%3DCode%26ref%3Dsearchresults%26q%3Dextension%3Arego%2Bpackage%2BNOT%2Bnothack&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&reserved=0.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-policy-agent%2Fopa%2Fissues%2F1413&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&reserved=0) which then
powers features like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fcontainers%2Foci-artifact-support-in-amazon-ecr%2F&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&reserved=0.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth

Re: OPA to graduation

Joe Beda <jbeda@...>

#5334

+1 NB

Agree with Gareth that there is no silver bullet here. Just like programming languages there are preferences and different needs and no one size fits all solution.

That being said, I think that OPA clearly hits a sweet spot and has a growing community. And the CNCF is welcoming to ~competing projects so graduating OPA doesn’t mean that other alternatives can’t also be supported and part of the CNCF umbrella.

One thing that I’d, personally, like to see is more standardization around the interfaces to these type of systems. Is it possible to replace OPA with another similar system and not have to retool the APIs to the policy engine? Would be interesting to standardize around some other interfaces to OPA too like the way that side-channel data is specified/presented and the way that decision information is surfaced back up to external monitoring/logging systems. (I’ve passed this on to the OPA folks so it should be a surprise to them.)

Joe

From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

Re: [RESULT] Emily Fox approved as co-chair for SIG Security

Santiago Torres Arias <santiago@...>

#5333

Congratulations, Emily!

Show quoted text

On Mon, Sep 28, 2020 at 08:00:00AM -0700, Amye Scavarda Perrin wrote:
Emily Fox for SIG Security Chair:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5303&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=cvOXQnL0uHd74hDyDWOe0iZEsP9S1ZpVsppc8T3glVw&e= 

+1 Binding
7/10
Justin Cormack: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5312&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6KQ1-f9Qvp8lvp7Dnek3HBZstjYYKfStdGKl5o_i5Ok&e= 
Michelle Noorali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5315&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=04IZ3omAAWlw-JHaDqfsb4JdiqPMRaw3dC5ZlzuvsOE&e= 
Liz Rice: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5318&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=9U4PNNfAolse9EAB8_omh3CquTnAwt3YcYPDYgHpW4k&e= 
Alena Prokharchyk: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5319&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zZKRzCO4AxhiTQp1jPX3pB-yRja2YHy7_JTEGAGf-a8&e= 
Katie Gamanji: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5325&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=MWg6pjA2b84djDnWe8icF7t4cyk8_moubqjUDkwNWdY&e= 
Saad Ali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5326&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6andbIBlUzi2azRgy9IMRV8XE0FThjPrtUtBxJVQRmo&e= 
Matt Klein: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5327&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=wayaW7SMvyJSwgvdHEF2adUjgYcwY8GGeVyGj7BxMro&e= 

+1 NB
Justin Cappos https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5304&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=VgDz3A2vY0X9uu-FtyYvpLLBu40Z1YyBFpT3gr5IYm0&e= 
Brandon Lum: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5305&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_NXLFJGgnHPNekVKtBnWJ-PyrVBPCZfv7V-tw_BreUs&e= 
Chase Pettet:https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5306&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=rXQfIwsfZPgIL6W5QVunCwXtSCTTRFBCqoLzNo5AWac&e= 
Paris Pittman: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5307&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=YhRp-Pnu64zHYnjyG7iu5sQVB5-94jE6gecu5V_WWtE&e= 
John Hillegass: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5308&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=dKFlVv-NvximxcyfrSHllJUQDAE3SD6nYJKjVp_HKxs&e= 
Sarah Allen: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5309&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_ozh93VFV5t9upw3ZHWLOhy9EdXOU9Y19ghJIp_QgmE&e= 
Gadi Naor: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5310&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hEV8M6oi_ucj7LDSkLXqVa7xAk-psCTsJn-jTjMF8Jk&e= 
Frederick Kautz: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5311&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=CZpg03KmYvGx4SZVmfa1q4ycqZtijdQVjn6rj6weWAE&e= 
Santiago Torres Arias: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5313&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=3pqvOZcIYtQYTDNAlGW6cZDpD6BOcbjG7FECxDY4t_0&e= 
Andrew Martin: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5314&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zUdOgoorgfkYG_RU0grNuZ-FtUR7HmEQVYsg47ipKXc&e= 
Ricardo Aravena: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5316&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hAn7nQ66xhQo_9G7Ll9jmvp13aexdz43itWcNRpkHqE&e= 
Siddharth Bhadri: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5320&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=DBmDhSYdY66kvFj0Sve0CJHprzNq4xvQ3TT6QylVgrU&e= 
Ashutosh Narkar: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5321&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=gqSIjvPUb_Ul1jqaPQ4PrTrxW6Fo2MmqFrjAq67XEO8&e= 
Andrés Vega: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5323&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=WIKFfvVmV4Ftavv48jonyHUqj-fx0MOjgCByR1ldYRk&e= 

-- 
Amye Scavarda Perrin | Program Manager | amye@...

signature.asc

[RESULT] Emily Fox approved as co-chair for SIG Security

Amye Scavarda Perrin

#5332

Emily Fox for SIG Security Chair: https://lists.cncf.io/g/cncf-toc/message/5303

+1 Binding

--

Amye Scavarda Perrin | Program Manager | amye@...

Re: OPA to graduation

Jim Bugwadia

#5331

+1 NB

I am a maintainer of Kyverno (https://github.com/nirmata/kyverno/blob/master/README.md), which as mentioned above is an alternative to OPA/Gatekeeper. We believe that policies are essential to wider (and safer) enterprise adoption of Kubernetes, which is why we built Kyverno to be easy to use and maintain for all Kubernetes users.

I agree with all the points above on the steep learning curve and ongoing challenges of managing OPA policies in Rego. However, my understanding of the incubating-to-graduation requirements is that they are based on project usage and maturity.

Assuming OPA meets all listed graduation requirements, and assuming that there will be other alternatives like Kyverno, etc. that will ideally become part of the CNCF ecosystem (Kyverno is planning sandbox submission), I see overall value and benefits in OPA graduating to help promote one available approach for managing policies in Kubernetes.

Regards,

Jim

Show quoted text

On Sun, Sep 27, 2020 at 2:10 AM Gareth Rushgrove <gareth@...> wrote:

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth

Re: OPA to graduation

Gareth Rushgrove

#5330

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth

Re: OPA to graduation

Gadi Naor

#5329

-1 NB

The community around this project is great and there is a consensus on problem space.

Having the benefit of solving and working with customers on Kubernetes security compliance and authorization challenges for quite some time, and integrating OPA as part of our engine - I've witnessed unanimous feedback that OPA REGO has a steep learning curve, and high touch ongoing costs.

Nowadays with building blocks such as WASM, and motion around IaC that use real programming languages (Pulumi & CDK) I believe the ecosystem should strive to make the life of engineering teams easier, possibly in their comfort zone programming language (hey, Go, JS ... can work fine on documents) rather than introducing a new, none intuitive, high touch programming language.

Also, with regards to OPA applications such as Gatekeeper , Kafka Authorizer, conftest and others - Are those OPA applications proposed for graduation?

Gatekeeper constraints and templates is gr8 - and I'd vote to graduate Gatekeeper with at least none REGO working PoC.

Gadi

Show quoted text

On Sat, Sep 19, 2020 at 7:49 PM <nuhamind2@...> wrote:

I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal

--

Gadi Naor

◆

CTO

US. 2443 Fillmore St, San Francisco, CA, 94115

IL. 5 Miconis St, Tel Aviv, 6777214

M. +972-52-6618811

Web. www.alcide.io
GitHub. github.com/alcideio

Securing Kubernetes & Service Mesh.
Anywhere.

Bridging Security & DevOps.

Cloud Native Virtual Summit is October 6-8. → Register HERE

CNCF Awards now open for nominations

Amye Scavarda Perrin

#5328

We're starting the nomination process for our ambassador, committer and community awards.

CNCF Top Ambassador: A champion for the cloud native space, this individual helps spread awareness of the CNCF (and its incubated projects). The CNCF Ambassador leverages multiple platforms, both online as well as speaking engagements, driving interest and excitement around the project.
CNCF Top Committer: This will recognize excellence in technical contributions to CNCF and its projects. The CNCF Top Committer has made key commits to projects and, more importantly, contributes in a way that benefits the project neutrally as a whole.
CNCF Chop Wood Carry Water: This is given to a community member who helps behind the scenes, dedicating countless hours of their time to open source projects + completing often thankless tasks for the ecosystem’s benefit. The winner of this award will be chosen by the TOC and CNCF Staff.

Nominations will open today, and close on October 16nd. We'll be announcing the awards at KubeCon + CloudNativeCon Virtual North America. Voting (open from October 19 through October 26th) will be performed using the CIVS tool, using emails from the CNCF database for the following groups:

CNCF Ambassadors are eligible to vote for the Top Ambassador
CNCF Maintainers are eligible to vote for the Top Committer

--

Amye Scavarda Perrin | Program Manager | amye@...

Re: [SIG-Security] Nomination of Emily Fox as co-chair

Matt Klein

#5327

+1

Show quoted text

On Mon, Sep 21, 2020 at 4:13 PM Jeyappragash Jeyakeerthi <jj@...> wrote:

Dear Technical Oversight Committee,

Dan Shaw’s term as co-chair of SIG-Security has come to an end. We would like to nominate Emily Fox as a new co-chair of SIG-Security (requiring a 2/3rd vote in compliance with the cncf-sig elections process).

Following are some of Emily’s accomplishments
As a tech lead and a member of the SIG-Security
Cloud Native Security Day Lead (two successful events, upcoming CFP)
Defined categories for supply chain compromise catalog PR#304
Process & governance (examples: assessment process docs, code of conduct)
Leading the whitepaper initiative (Issue #138)
Professional affiliations:
DevOps Security Lead, NSA
Github: @TheFoxAtWork
CNCF Projects: n/a
SIG-Security commits

Thanks!
JJ in collaboration with other SIG-Security co-chairs (Dan and Sarah) and TOC Liaisons Liz Rice & Justin Cormack

Re: [SIG-Security] Nomination of Emily Fox as co-chair

Saad Ali

#5326

+1 binding

Thank you for volunteering!

Re: [SIG-Security] Nomination of Emily Fox as co-chair

Katie Gamanji

#5325

+1 binding

Exciting times!

Show quoted text

On Tue, 22 Sep 2020, 20:44 , <andresvega1@...> wrote:

+1

Emily has gone above and beyond to avail herself as a technical leader to the community. Among many other things, she was instrumental in the review of the SPIFFE/SPIRE security assessment.

-Andres

Re: Sandbox Projects included from September 8 TOC meeting

John Belamaric

#5324

We discussed this in the SIG Architecture meeting today. While generally workload controllers are within scope of the Kubernetes project, it is up to SIG Apps to decide if they are willing to take these on as SIG-sponsored projects. As Matt suggests, it's fine for these to exist as external workload controllers.

With respect to upstreaming, the preference of SIG Arch would be to see individual features move into existing workload controllers as they mature, rather than creation of whole new controllers. The goal here would be to avoid a proliferation of controllers that makes choices very difficult for consumers. Of course, if there is some fundamental difference between the new controller and all existing ones, then a new one may be warranted. But creation of a new one should be done with an abundance of caution. Again this would ultimately be the decision of SIG Apps.

Thanks,

John

Show quoted text

On Mon, Sep 21, 2020 at 1:31 PM <szihaI@...> wrote:

The OpenKruise project agree with the Sig App's assessment completely. We, too, believe while up-streaming some of the features to the core workloads is possible, the majority of the controllers and features is best to remain as a separate project.

Best regards,
Andy Shi