|
Re: OPA to graduation
Torin Sandall
Hi Maor, https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.) -Torin
On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
--
-Torin
|
|
|
|
Re: OPA to graduation
Maor Goldberg <maor@...>
Hey,
toggle quoted messageShow quoted text
Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations? I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). I think it will be great to see more than one organization sharing responsibility and leadership for this important project. Good luck, Maor. 
On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote: Folks The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520) The due dilligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread. Brendan Burns
|
|
|
|
Re: [RESULT] KubeEdge to move to Incubation
Congrats at KubeEdge Project!
Look forward to more deployment.
Thank you,
Tina ^ ^
On Sep 16, 2020, at 1:22 PM, Quinton Hoole via lists.cncf.io <quinton=hoole.biz@...> wrote:
|
|
|
|
Re: [RESULT] KubeEdge to move to Incubation
Quinton Hoole <quinton@...>
Congrats KubeEdge! Very well earned, IMO. Q
On Wed, Sep 16, 2020 at 8:01 AM Amye Scavarda Perrin <ascavarda@...> wrote:
--
Quinton Hoole quinton@...
|
|
|
|
Re: OPA to graduation
Quinton Hoole <quinton@...>
As some of you are probably aware, I've been a strong proponent of OPA for several years now. Both the project, and the team seem like a great fit for CNCF graduation. I have not yet read the full due diligence, but I can state that I am not aware of any fundamental blockers to graduation, and would love to see it proceed successfully. (note: I have zero professional affiliations with the project - the above represent my best attempt at an unbiased opinion). Q
--
Quinton Hoole quinton@...
|
|
|
|
OPA to graduation
Brendan Burns
Folks
The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)
The due dilligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.
Brendan Burns
|
|
|
|
[RESULT] KubeEdge to move to Incubation
Amye Scavarda Perrin
KubeEdge is approved to move to incubation: https://github.com/cncf/toc/pull/461 7/10 Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5017 Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5030 Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5043 Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5050 Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5053 Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5067 Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5249 +1 NB: Davanum Srinivas: https://lists.cncf.io/g/cncf-toc/message/5018 Zhipeng Huang: https://lists.cncf.io/g/cncf-toc/message/5019 Felix: https://lists.cncf.io/g/cncf-toc/message/5020 Klaus Ma: https://lists.cncf.io/g/cncf-toc/message/5021 Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/5022 Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/5023 Andrew Aitken: https://lists.cncf.io/g/cncf-toc/message/5024 Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/5025 Thor Anker Kvisgård Lange: https://lists.cncf.io/g/cncf-toc/message/5026 Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/5027 Jeremy Rickard: https://lists.cncf.io/g/cncf-toc/message/5030 Dejan Bosanac: https://lists.cncf.io/g/cncf-toc/message/5032 Paul Buck: https://lists.cncf.io/g/cncf-toc/message/5033 Phillipe Robin: https://lists.cncf.io/g/cncf-toc/message/5040 Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/5041 Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/5042 Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/5044 Kevin Ryan: https://lists.cncf.io/g/cncf-toc/message/5045 Anni Lai: https://lists.cncf.io/g/cncf-toc/message/5046 Steve Wong: https://lists.cncf.io/g/cncf-toc/message/5061 GolfenGuo: https://lists.cncf.io/g/cncf-toc/message/5070 Feilong Wang: https://lists.cncf.io/g/cncf-toc/message/5079 Qingchen Job: https://lists.cncf.io/g/cncf-toc/message/5131 Shenkh: https://lists.cncf.io/g/cncf-toc/message/5132 Ryan: https://lists.cncf.io/g/cncf-toc/message/5133 Plutoligs: https://lists.cncf.io/g/cncf-toc/message/5134 Zhiyiliu: https://lists.cncf.io/g/cncf-toc/message/5135 Stanley: https://lists.cncf.io/g/cncf-toc/message/5136 Zongkheshuaige: https://lists.cncf.io/g/cncf-toc/message/5137 Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
Agenda for 9/15
Amye Scavarda Perrin
Hi all, We'll be meeting tomorrow with a presentation on the latest End User Tech Radar. Presentation: https://docs.google.com/presentation/d/1egNKT1d5vthITnM03D9EheHqn0iBkkjBLFinVNtHZug/edit?ts=5f5f468a#slide=id.g25ca91f87f_0_0 Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
Re: [RESULT] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
Thanks, Amye for the summary, and thank you All for your trust! (: Looking forward to what we can achieve together in the CNCF Observability space 💪 Kind Regards, Bartek Płotka (@bwplotka)
On Tue, 8 Sep 2020 at 22:55, Amye Scavarda Perrin <ascavarda@...> wrote:
|
|
|
|
Re: Sandbox Projects included from September 8 TOC meeting
Li, Xiang
(I am familiar with the team behind the project, and the background of the project). OpenKurise itself is not an experiment. It supports some of the largest Kubernetes clusters in production environment at Alibaba and a few other large internet companies (https://github.com/openkruise/kruise/issues/289). For any sizable companies using Kubeternetes, it is not uncommon to have tens of generic controllers that are not specific to any particular application. The motivation of OpenKruise project is to find a subset of these controllers that are commonly useful to a number of users rather than just one company. So we can reduce some duplication, improve collaboration and help the community to grow. Yes, if some enhancements or workload types are popular enough that everyone wants then, we hope them to be upstreamed to Kubernetes project itself.
|
|
|
|
Re: Sandbox Projects included from September 8 TOC meeting
Amye Scavarda Perrin
The recording for the 9/8 meeting is up on YouTube: https://www.youtube.com/watch?v=q_FO3PWnkY4
On Wed, Sep 9, 2020 at 10:36 AM Liz Rice <liz@...> wrote:
--
Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
Re: Sandbox Projects included from September 8 TOC meeting
Liz Rice
OpenKruise is experimenting with a number of workload-related resource definitions, some of which are enhancements to existing core K8s resources. We're happy to see these experiments and want to support them, but we wondered if it makes more sense for them to belong within the purview of the Kubernetes project rather than as a standalone project? My understanding is that OpenKruise intends to eventually contribute successful experiments to upstream Kubernetes anyway. There's also a question about project scope. If the Kubernetes project would actually prefer these experiments to take place in a separate project, does that make OpenKruise the natural home for all workload-related CRD ideas, or some other scope? The discussion was recorded (I'm sure Amy can provide the link if she hasn't already circulated it) and that might be worth listening to for more context, if you have the time.
On Wed, Sep 9, 2020 at 4:21 PM Matt Farina <matt@...> wrote:
|
|
|
|
Re: Sandbox Projects included from September 8 TOC meeting
Matt Farina
OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project. For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project?
On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
|
|
|
|
Sandbox Projects included from September 8 TOC meeting
Amye Scavarda Perrin
The TOC has reviewed the current Sandbox projects applying for inclusion. The projects included are: Backstage Tremor metal3-io Porter OpenYurt Open Service Mesh Other projects not brought to vote: checkov - further conversation needed re: roadmap, holding for updated roadmap protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject? Predator - no clear roadmap, resubmit with clearer roadmap SchemaHero - no clear roadmap, resubmit with clearer roadmap Keylime - scheduled for next closed meeting, September 22 As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" Welcome to these new sandbox projects! -- Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
[RESULT] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
Amye Scavarda Perrin
The Tech Lead nomination for SIG Observability - Bartłomiej Płotka passes. (https://lists.cncf.io/g/cncf-toc/message/4957) 7/10 +1 Binding Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5123 Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5125 Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5127 Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5157 Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5165 Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5194 Xiang Li: https://lists.cncf.io/g/cncf-toc/message/5271 +1 NB Oleg Chornyi: https://lists.cncf.io/g/cncf-toc/message/4958 Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/4959 Nikhita Raghunath: https://lists.cncf.io/g/cncf-toc/message/4960 Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/4962 Marco Pracucci: https://lists.cncf.io/g/cncf-toc/message/5124 Rob Skillington: https://lists.cncf.io/g/cncf-toc/message/5124 Rajat Vig: https://lists.cncf.io/g/cncf-toc/message/5129 Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/5146 Andrew Aitken: https://lists.cncf.io/g/cncf-toc/message/5194 Kevin Wang: https://lists.cncf.io/g/cncf-toc/message/5251 Ozan Minez: https://lists.cncf.io/g/cncf-toc/message/5251 Mahesh Manjunath Nayak: https://lists.cncf.io/g/cncf-toc/message/5168 Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
Re: [EXTERNAL] Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
Li, Xiang
+1 binding
|
|
|
|
Re: [VOTE] Rook Graduation
+1 NB.
|
|
|
|
Re: Istio Steering Committee
Josh Berkus
On 9/2/20 2:49 PM, Matt Wilson wrote:
I think this is an interesting conversation, but it doesn'tYeah, I would love to see more of the other discussion on the gov-wg ML. Pick it up there? I would like to make a suggestion: none of what I have seen proposedThe "proof" is where it is. If there are people who are allowed to merge code/docs for the project and work for multiple organizations, that's probably the strongest proof we can obtain that contributions are not limited by employer. It is definitely true that there are other possible demonstrations of openness to contributions. That's why I asked the TOC to rule on a rationale; by making the *reason* paramout, SIGS/TOC are a position to judge borderline cases. And if open source is good for anything, it's creating borderline cases. Rather than focusing on various tests and studying past events, I...not quite sure what you're saying here, in practical terms. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
|
Re: Istio Steering Committee
On Wed, Sep 2, 2020 at 09:22 AM, Josh Berkus wrote:
I'm not personally aware of a good example of a strict quorum voting structure that provided an empowering voice or an ability for people who are not technically as deep. But I am definitely curious to learn more about effective practices put in place by communities, keeping in mind that effective practices for one group of humans may differ for another. Is there one I should study more closely? The other problem is avoiding "captive" users. If a project'sThis is one of the areas where I continue to struggle to understand the concern. To me, open-source licenses make it difficult to hold users/adopters "captive." When vendors make an attempt to do so, it can result in others stepping up to create better, more "open" conditions. Sometimes (historically, rarely) that means starting a new community, since that is something that open-source licenses enable. The voices of "freeware" users is an important and valuable. When it comes to how a vendor invests their time, I think that paying attention to paying customers is a natural thing to do. Paying attention to non-paying customers can be a very important part of your business, especially in growing your business. I do not think that a vendor has an obligation to provide free services or development for "freeware" users. Also, I do not think that there needs to be some structural element to open-source governance recommendations, to "ensure" that a project is being "open enough." I think this is an interesting conversation, but it doesn't necessarily get closer to resolving https://github.com/cncf/toc/issues/459. I would like to make a suggestion: none of what I have seen proposed can _guarantee_ that "the project is open to contributions regardless of employer" as was summarized as the objective in https://github.com/cncf/toc/issues/459#issuecomment-641550257. It seems that what is being asking for is evidence, or perhaps "proof", as embodied a project's documentation (as proposed with the SC concept) or commit history (as it currently stands in the graduation criteria), that they are open to contributions from all. What matters far more to _me_ is what happens in cases where a project is faced with disagreements, and how they are resolved constructively and collaboratively. And it may be that a community has never faced any material disagreement. Rather than focusing on various tests and studying past events, I would rather see the TOC and (only in the very rarest of circumstances) GB be able to act as an ombudsman for those rare significant disagreements that reach an impasse, because each circumstance of disagreement is going to be unique and can require a collection of facts before judgment. --msw
|
|
|
|
Re: Istio Steering Committee
Josh Berkus
On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*This can actually be a great structure for a project with a small number of vendors doing most of the technical work, but larger number of users. The difficulty is recruiting users with a sufficient depth of technical knowledge to have meaningful input, e.g. if the end-user SC members don't really understand the API, they're not gonna spot a breaking change. The other problem is avoiding "captive" users. If a project's leadership group contains only the staff of one vendor, and that vendor's commercial users, then it's still a single-company project. You'd need to have at least a few "freeware" users in there to mix things up. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
