|
Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
Justin Cormack
+1 binding
On Thu, Jul 9, 2020 at 11:45 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Gadi Naor
-1 NB ... from a security perspective, i cant up vote this project despite my appreciation - at this point I am concerned on how a fork maintain security patches of mainline k8s.
On Tue, Aug 4, 2020 at 12:03 AM Jimmy Song <jimmysong@...> wrote:
--
Securing Kubernetes & Service Mesh. Anywhere. Bridging Security & DevOps.
|
|||||||||
|
|
|||||||||
|
Agenda for 8/4
Amye Scavarda Perrin
Hi all,
We'll be meeting tomorrow with a SIG update meeting. Agenda: https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit# Presentation: https://docs.google.com/presentation/d/1197FJB18hUjZHY2A3XsTL8Y46aqJmB4hfESB4-ccHVo/edit#slide=id.g25ca91f87f_0_0 Thanks! -- Amye Scavarda Perrin | Program Manager | amye@...
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
김 진용 <jykim@...>
+1 NB
JINYONG KIM | 김진용 CEO | 대표이사
NexCloud http://www.nexcloud.co.kr http://www.nexclipper.io O 02-533-8622 M +82
10-2048-8697 F 02-533-8623
보낸
사람:
"cncf-toc@..." <cncf-toc@...>(wuheng <wuheng@...>
대신)
+1 NB
发自 WPS邮箱客戶端 在 Mofei Zhang <mofei2816@...>，2020年8月1日 19:34写道：
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Jimmy Song <jimmysong@...>
toggle quoted messageShow quoted text
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Justin Cormack
+1 binding k3s has made it clear that it is not a fork and that is not the road it is going down. It is a distro, and I feel that distros are valuable work in open source, with many examples. The sandbox is a place for experiments, and allowing it in does not prejudge what road it may take from here on. Justin
On Fri, Jul 31, 2020 at 4:04 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Darren Shepherd
I'm probably jumping into the conversation uninformed and without context. I just want to make it very clear k3s is in no way shape or form a fork. There is nothing technically correct about calling it a fork. While k3s does include some modifications to
k8s code (about 300 lines or less), it is completely inline with the spirit of Linux distributions that carry their own patches for upstream components. The patches we carry largely have to do with enabling how k3s packages k8s (single binary).
Furthermore k3s has a proven track record already of keeping inline with every k8s minor and patch release. Patch releases are released withing days or in the case of a CVE the same day. Minor releases sometimes take a couple weeks to deliver, but we are trying
to get that to day. We have zero intention of diverging from upstream.
Please, please do not call k3s fork. It isn't a fork. I understand why some might have come to that conclusion, but it's neither technically true or the intention of the project.
Darren
From: cncf-toc@... <cncf-toc@...> on behalf of Bob Wise via lists.cncf.io <bob=bobsplanet.com@...>
Sent: Monday, August 3, 2020 6:51 AM To: alexis richardson <alexis@...> Cc: aprokharchyk@... <aprokharchyk@...>; Joe Beda <jbeda@...>; wisebob@... <wisebob@...>; Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...> Subject: Re: [cncf-toc] [VOTE] k3s for Sandbox K3s is a distro, and it is a fork as well. The "opinionated" description always applies to distros (which can be more or less opinionated, of course). If the opinion included things like backported security patches (does it?) that are available upstream
but not for all versions, then I'd be inclined to agree that the spirit of the distro is not to be a fork.
That does not appear to be the case for K3s, which is a conformant fork. The comments about encouraging mending of fences and contribution upstream are further evidence of the forked nature of the project.
The TOC has distinct if related questions to address:
1) Will the TOC sponsor project forks into sandbox?
2) Will the TOC sponsor project distros into sandbox?
3) Is there something nuanced about sponsoring these into sandbox vs a track towards incubation and graduation? If the purpose of the sandboxing of K3s were to give it a more neutral home while the forks are upstreamed and fences are mended, then that
seems like a reasonable use of sandbox. If the track here is to put a fork onto a graduation path then that is much more concerning.
4) Kubernetes conformance tests are what determine distro eligibility. These tests are always evolving. What happens if a sponsored distro (or fork) stops passing conformance?
FWIW, I agree on the k8s sandbox point.
-Bob
On Fri, Jul 31, 2020 at 11:38 AM alexis richardson <alexis@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Brendan Burns
+1, binding.
From: cncf-toc@... <cncf-toc@...> on behalf of Sheng Liang via lists.cncf.io <sheng=rancher.com@...>
Sent: Sunday, August 2, 2020 7:47 AM To: liz@... <liz@...> Cc: Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...> Subject: [EXTERNAL] Re: [cncf-toc] [VOTE] k3s for Sandbox +1 binding
On Aug 2, 2020 12:13 AM, "Liz Rice via lists.cncf.io" <liz=lizrice.com@...> wrote:
+1 binding
On Sat, 1 Aug 2020 at 09:22, Richard Hartmann <richih@...> wrote:
+1 NB
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Liz Rice
Per Bob's point 3, k3s want a neutral home for further experimentation and collaboration; in my opinion it is undoubtedly cloud native, and it solves a particular problem in a way that lots of folks find useful, so (again IMO) CNCF is the natural organization for it to get that neutral home. Should that be within k8s or as a standalone project? After the conversation with k8s Steering I believe a separate project is the path where k3s is most likely to succeed at this stage, and it doesn't place any new requirements or burden on the k8s team. As Alena, Michelle and others have mentioned, being part of the same foundation gives us an opportunity for better communication and alignment between projects going forward. k3s have stated their intention to remain conformant, and that's a big part of why I think there is potential for success here.
On Mon, Aug 3, 2020 at 2:51 PM Bob Wise <bob@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Bob Wise
K3s is a distro, and it is a fork as well. The "opinionated" description always applies to distros (which can be more or less opinionated, of course). If the opinion included things like backported security patches (does it?) that are available upstream but not for all versions, then I'd be inclined to agree that the spirit of the distro is not to be a fork. That does not appear to be the case for K3s, which is a conformant fork. The comments about encouraging mending of fences and contribution upstream are further evidence of the forked nature of the project. The TOC has distinct if related questions to address: 1) Will the TOC sponsor project forks into sandbox? 2) Will the TOC sponsor project distros into sandbox? 3) Is there something nuanced about sponsoring these into sandbox vs a track towards incubation and graduation?
If the purpose of the sandboxing of K3s were to give it a more neutral home while the forks are upstreamed and fences are mended, then that seems like a reasonable use of sandbox. If the track here is to put a fork onto a graduation path then that is much more concerning.
4) Kubernetes conformance tests are what determine distro eligibility. These tests are always evolving. What happens if a sponsored distro (or fork) stops passing conformance? FWIW, I agree on the k8s sandbox point. -Bob
On Fri, Jul 31, 2020 at 11:38 AM alexis richardson <alexis@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Saad Ali
Abstain
Unfortunately I missed the "Joint CNCF TOC/Kubernetes Steering Committee" meeting. But I talked to some folks afterwards to fill me in. Overall, I'd like to avoid setting precedent that a project unable to generate consensus within the Kubernetes community, can bypass the community by going straight to the CNCF. While that may not be what happened here, k3s feels very similar to Kind (https://github.com/kubernetes-sigs/kind) and minikube (https://github.com/kubernetes/minikube) both of which are Kubernetes sub-projects. I would like to to see k3s follow the same approach as those projects and apply to become a k8s sub-project first, rather than a standalone CNCF sandbox project. This would ensure consistency, and give me confidence that Kubernetes experts have reviewed the project. Even if the k8s community ultimately says no, it wouldn't mean automatic no for a stand alone CNCF project, but would provide valuable insight for a CNCF application. While I realize that building technical consensus is hard, especially in a project as large as Kubernetes, I believe doing so is critical for healthy communities. Why not vote "-1"? The revised CNCF Sandbox project guidelines lower the bar for sandbox, making it a *tool* that can be used by anyone who needs a neutral place to host IP and collaborate on new projects with minimal overhead rather then a stepping stone towards incubation/graduation. This lets the TOC and CNCF SIGs to be more discriminating for incubation/graduation projects (only accept projects at that level that "makes sense in the CNCF ecosystem") while allowing the sandbox to serve as a test bed for innovation.
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] TiKV Graduation
Liu Tang
+1, NB
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Reitbauer, Alois
+1 nb
From: <cncf-toc@...> on behalf of "Phil Estes via lists.cncf.io" <estesp=gmail.com@...>
+1 nb
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Sheng Liang <sheng@...>
+1 binding
On Aug 2, 2020 12:13 AM, "Liz Rice via lists.cncf.io" <liz=lizrice.com@...> wrote:
+1 binding
On Sat, 1 Aug 2020 at 09:22, Richard Hartmann <richih@...> wrote:
+1 NB
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Liz Rice
+1 binding
On Sat, 1 Aug 2020 at 09:22, Richard Hartmann <richih@...> wrote: +1 NB
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
wuheng
+1 NB 发自 WPS邮箱客戶端 在 Mofei Zhang <mofei2816@...>，2020年8月1日 19:34写道：
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Mofei Zhang
+1 NB
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Richard Hartmann
+1 NB
I see it as a learning tool, which has merit in and as of itself. Similar to how Cortex and Thanos help shape the future for Prometheus, k3s can act as a canonical proving ground of sorts before taking things upstream. While not distinct projects themselves, both prometheus-community and prometheus-operator (recently moved out of its old coreos/ home) also help shape and advance core Prometheus. k3s just happens to have more people on it than the two prometheus-* mentioned here. On Fri, Jul 31, 2020 at 5:04 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Matt Farina
+1 nb I appreciate that the TOC took the time to talk with the Kubernetes Steering Committee prior to calling for a vote. I can't imagine a vote moving forward without their blessing. It's great that the TOC took the time to do that. As a maintainer that maintains a CNCF project that came out from under the Kubernetes umbrella, I understand how there is more than just an association when being a sub-project of another project. Kubernetes has certain ways it does things. And, it's easy for sub-projects to get lost in that setup. If people have a different style of maintaining it can be really useful for that project to live elsewhere. If folks don't know, if a project like k3s were to join Kubernetes as a sub-project their governance, CI, and processes would all need to change to conform to Kubernetes. This is one of the ways the Kubernetes projects manages to many people and so much work. There are standards and processes that need to be followed. It makes things far easier on the project. Kubernetes has now had several projects move out from it's umbrella to be CNCF projects. It's great to watch projects grow enough that they can be separate projects on their own. I read there's concern about projects being entangled with companies when they join the CNCF. In this case, Rancher. I've seen this before as I've watched the CNCF grow. It happened with a recent incubation project ... it's not just a sandbox thing. The CNCF staff does a good job of guiding the projects to straighten this stuff out given a little time and patience. I wouldn't consider this a blocker... more a task to be worked out if k3s goes in to the CNCF. I also want to point out that it's hard and time consuming to get architecture changes into upstream Kubernetes. Sometimes they aren't even going to happen for various reasons... even if it would be useful. An alternative place to prove out proposed changes would give them a higher likelihood of getting into Kubernetes itself. It would also prove out that there are people who can maintain those changes. This is why I like k3s trying something out and proving it's useful and can work. - Matt
On Fri, Jul 31, 2020, at 2:57 PM, Michelle Noorali wrote:
|
|||||||||
|
|
|||||||||
|
Re: [VOTE] k3s for Sandbox
Christian Posta
Big fan of k3s! +1 NB
On Fri, Jul 31, 2020 at 8:04 AM Amye Scavarda Perrin <ascavarda@...> wrote:
--
|
|||||||||
|
|
