Date   

CNCF position on new Docker policy limiting image retention

Yuri Shkuro
 

Starting Nov 1, 2020, Docker is planning to limit retention of images on Docker Hub for free accounts to 6m [1]. This will likely affect many CNCF projects that distribute binaries. For example, while the Jaeger projects makes multiple releases per year, it does not mean that all users are upgrading more frequently than 6m. We also have a number of build and CI related images that are not updated that often, and if they start TTL-ing out it will introduce additional maintenance burden.

What is the TOC recommendation on this front? Should CNCF upgrade some of Docker Hub accounts (e.g. starting with graduated projects) to paid plans?

[1]: https://www.docker.com/pricing/retentionfaq


Re: k3s sandbox proposal

craig@...
 

Hi everyone,

Per the TOC's recommendation, the K3s team has updated our README.md to include a roadmap and some other information that hopefully helps clarify what K3s is and isn't. We appreciate the TOC's guidance and the community's feedback in the voting thread to help us improve in these areas. We look forward to continuing in this direction!

https://github.com/rancher/k3s

Regards,
Craig J


Re: [VOTE] Rook Graduation

Saad Ali
 

+1 Binding


Re: [VOTE] TiKV Graduation

Saad Ali
 

The TOC discussed the concerns around the PD dependency this morning. Given Liu's indication that the library could be migrated to the TiKV project, let's go ahead and do that. Liu, can you please update https://github.com/cncf/toc/pull/414 with the migration status. We can kick off voting again once that is done.


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Michelle Noorali <michelle.noorali@...>
 

+1 binding

On Sun, Aug 9, 2020 at 1:13 PM Quinton Hoole <quinton@...> wrote:
+100 NB.  Great!

Q

On Thu, Jul 9, 2020, 15:45 Amye Scavarda Perrin <ascavarda@...> wrote:
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] TiKV Graduation

Liu Tang
 

Thanks TOC for raising this concern.  I am Tang Liu, and I am speaking here both as a TiKV maintainer and a member of the broader eco-system & community.

It’s true that Placement Driver is an indispensable part for TiKV, as the meta store and central scheduling center.

The original rationale behind the current placement of PD (under PingCAP with TiDB, the distributed SQL database) is to take PD as a significant dependency library in the TiDB eco-system (TiKV included) and other TiKV-alike stores as well.

Besides TiKV, there are multiple major TiDB features or components that depend on PD. For example, Dashboard (https://docs.pingcap.com/tidb/dev/dashboard-intro), our visual diagnosis platform, depends on PD to obtain necessary data. Unistore (https://github.com/ngaut/unistore), a KV store in GO to quickly validate TiDB optimizations depends on PD to deploy and run. Some scenario based features like multi-data center are made possible by PD. Outside of TiDB, there are other projects building distributed KV stores based on PD. 

With a vibrant TiDB ecosystem of almost 1000 adopters and other PD based projects,  we believe PD has been in a health and sustained maintenance and has formed its own eco-system over time.  

However, if this could not clear the concern of TOC, we are willing to migrate the entire PD library to the TiKV project.

Liu Tang

Frederick Kautz <frederick@...> 于2020年8月11日周二 上午4:51写道:

It is described as "Placement driver for TiKV" and TiKV appears to have a strong dependency on it so perhaps pd should be considered part of TiKV? We should ask TiKV maintainers about this.

On Mon, Aug 10, 2020 at 1:20 PM Erin Boyd <eboyd@...> wrote:
Hi Liz,
We may have missed this.
I can take a look and get back to you asap.
Thanks,
Erin

On Mon, Aug 10, 2020, 2:17 PM Liz Rice <liz@...> wrote:
Finally reviewing the TiKV graduation application. Mostly it looks great to me but has there been any discussion of TiKV's dependency on https://github.com/pingcap/pd??? I’m not familiar with PD so I’m just raising the question of whether this is reasonable. We have plenty of projects with dependencies (e.g. on very widely used database, or k8s use of etcd before etcd came into the foundation) but I’d like some reassurance about whether PD is in the same kind of class as these, or whether there is a Plan B in the event that for some reason PD were no longer to be maintained. Thoughts welcome! 


On Mon, 3 Aug 2020 at 08:46, <tl@...> wrote:
+1, NB


Re: [VOTE] TiKV Graduation

Frederick Kautz
 

It is described as "Placement driver for TiKV" and TiKV appears to have a strong dependency on it so perhaps pd should be considered part of TiKV? We should ask TiKV maintainers about this.

On Mon, Aug 10, 2020 at 1:20 PM Erin Boyd <eboyd@...> wrote:
Hi Liz,
We may have missed this.
I can take a look and get back to you asap.
Thanks,
Erin

On Mon, Aug 10, 2020, 2:17 PM Liz Rice <liz@...> wrote:
Finally reviewing the TiKV graduation application. Mostly it looks great to me but has there been any discussion of TiKV's dependency on https://github.com/pingcap/pd??? I’m not familiar with PD so I’m just raising the question of whether this is reasonable. We have plenty of projects with dependencies (e.g. on very widely used database, or k8s use of etcd before etcd came into the foundation) but I’d like some reassurance about whether PD is in the same kind of class as these, or whether there is a Plan B in the event that for some reason PD were no longer to be maintained. Thoughts welcome! 


On Mon, 3 Aug 2020 at 08:46, <tl@...> wrote:
+1, NB


Re: [VOTE] k3s for Sandbox

Bob Wise (AWS)
 

The chasm statement is interesting in the abstract. The well-deserved implication is “production use” is far to broad a term for a huge variety of situations, and I withdraw the question. Has the project made it clear how and when security issues (both under embargo and not) that are upstream will be handled, or not? That way the users can make their own judgements about whether that is acceptable risk for whatever their usage scenario is.

 

Conformance is a set of test cases. You don’t need to (nor should you) have to have any set of upstream code to pass conformance. This is good and as it should be. It can be both true that a project is conformant, and be either a fork or a complete re implementation. We tripped over this way back when during the Openstack days, and I think the Kubernetes project took the lesson. It is also possible to configure a non-forked/upstream distro to not pass conformance.

 

Consequently, statements of the form, “x is not a fork because it is conformant” are misleading.

 

Forks represent a compatibility risk for users. Again, the users are the ones that need to evaluate the risk and decide how fully they believe conformance covers their intended usage. We should be clear with the communities and users so they are able to make their own judgements.

 

To your specific comment: It’s not about whether etcd is present. That’s not what I was saying. It’s about whether the code that is needed to replace etcd with something else is a fork.

 

-bw

 

From: Matt Farina <matt@...>
Date: Monday, August 10, 2020 at 12:21 PM
To: "Wise, Bob" <wisebob@...>, CNCF TOC <cncf-toc@...>
Subject: RE: [EXTERNAL] [cncf-toc] [VOTE] k3s for Sandbox

 

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.

 

I can speak to some of this...

 

Are we clear about sandbox projects as “not recommended for production”

 

The CNCF describes projects in terms of crossing the chasm. You can find that here. Sandbox is labeled as being for the innovators.

 

A production recommendation really depends on who you are. An enterprise is different from an early stage startup. What one would suggest be used in prod for a new startup or for The Home Depot is going to be very different. I like the description in terms of the technology adoption lifecycle instead.

 

The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.

 

This brings up a good question that, I think, is a bit more complicated. What parts of Kubernetes are required to be present to be conformant? I would leave this up to the conformance folks. For example, would the use of Virtual Kubelet (another sandbox project) be a change to mean to far to allow? Why?

 

From the perspective of someone deploying workloads into a cluster I don't see how it matters if the API and environment is conformant for me to run workloads in.

 

If I'm missing something I would be curious to know.

 

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

 

This idea isn't new. It has been brought up before. While I can't state where this sits today I do know that bringing in new ideas to k8s can be difficult now because of people working in certain ways to maintain them. In the past SIG Architecture would tell people to innovate things out of tree. If it was a good idea and proved to be useful then K8s would potentially look to bring it back in house.

 

I like this idea. But, I think it needs to be proved out of tree before it can be brought in.

 

On Mon, Aug 10, 2020, at 1:48 PM, Wise, Bob wrote:

To me, this does not feel like either of those two upstream projects. Characterizing k3s as packaging only or tooling used to manage Kubernetes is not addressing:

 

  1. The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.
  2. The precedent setting for both distros and forks.
  3. Security posture w.r.t. to the PSC and embargo issue handling. Not arguably relevant if the project stays in sandbox, but relevant to all those that follow and critical if the path is incubation-bound. Are we clear about sandbox projects as “not recommended for production”?

 

Was there a voted-on statement from the Kubernetes Steering committee on this? Were the statements made more of the “we aren’t the TOC so we don’t have standing to object”, or “wow this is awesome and we support it”?

 

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

 

-Bob

 

From: <cncf-toc@...> on behalf of Matt Farina <matt@...>
Date: Monday, August 10, 2020 at 10:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: RE: [EXTERNAL] [cncf-toc] [VOTE] k3s for Sandbox

 

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.

 

I expect there are many people in this thread that lack some context. So, I figured I'd try to add some. If someone has more to add or a correction please do so. These are intermixed with some of my personal opinions, of course.

 

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.

 

There are two things about this that jump out to me.

 

First, kind, k3s, and minikube are different in ways that are important to those who use them. Those subtle differences matter. This happens with other distros, too.

 

kind was developed with Kubernetes test infrastructure automation in mind. In fact, the docs say "kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.". Minikube, which has been around a lot longer, targets Kubernetes application developers. Their docs note, "minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit."

 

This distinction is important as we see people performing different roles. Tools for those different roles will likely look different in the end.

 

k3s targets a different group from these other two. Their docs note, "The certified Kubernetes distribution built for IoT & Edge computing". This is a different situation from the other two and I would expect the experiencing of using it to look different.

 

It may feel the same on the surface but the subtle goals are going to lead it in some different directions. Those are good as one size does not fit all.

 

Second, while minikube and kind are k8s sub-projects that doesn't mean all distros that fall under the CNCF need to be. kind you would expect to be be part of the kubernetes project because it was developed with testing kubernetes itself in mind. If minikube were started today it may have been something entirely separate from the kubernetes project. Over the years we have had discussions and debates on this theoretical topic.

 

The idea that all of these things must or should be part of the Kubernetes project doesn't fit with the discussions the k8s community has had over the years. In fact, people come to Kubernetes with ideas for changes and we regularly tell them to do them as part a different project rather than in k8s.

 

I'm surprised to see a push for distros that are open source to be part of the k8s project if they are to be in the CNCF.

 

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.

 

I would prefer to see diversity over consistency. If a distribution is conformant (we have tests for that) there should be room for diversity in the way things are done. Sometimes this will be experiments. Sometimes that will mean one distro is not consistent with another. For example, some distros ship with CRDs pre-installed which means an extended API. Sometimes that will mean someone swapped out a component with another version that uses the same APIs.

 

The sandbox is a great please to experiment in a cross company way.

 

The k8s community is amazingly busy. The people are busy. I wouldn't want to put more on their plates but rather take it off. Enabling groups to operate autonomously from each other or in a loosely coupled manner helps with that. Sub-projects of Kubernetes are limited in their ability to do that. A product of Kubernetes trying to efficiently handle the scale of people and decisions.

 

Being a separate CNCF project enables a loose coupling. It doesn't add work to an overworked k8s community but enables collaboration. This is an often overlooked element.

 

Open source projects aren't companies that fall along nice divisional lines. They are far more organic while variance in people, process, and ideas flourish. A fertile place for that is important.

 

On Mon, Aug 3, 2020, at 5:06 AM, Saad Ali via lists.cncf.io wrote:

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

Erin Boyd
 

Hi Liz,
We may have missed this.
I can take a look and get back to you asap.
Thanks,
Erin

On Mon, Aug 10, 2020, 2:17 PM Liz Rice <liz@...> wrote:
Finally reviewing the TiKV graduation application. Mostly it looks great to me but has there been any discussion of TiKV's dependency on https://github.com/pingcap/pd??? I’m not familiar with PD so I’m just raising the question of whether this is reasonable. We have plenty of projects with dependencies (e.g. on very widely used database, or k8s use of etcd before etcd came into the foundation) but I’d like some reassurance about whether PD is in the same kind of class as these, or whether there is a Plan B in the event that for some reason PD were no longer to be maintained. Thoughts welcome! 


On Mon, 3 Aug 2020 at 08:46, <tl@...> wrote:
+1, NB


Re: [VOTE] TiKV Graduation

Liz Rice
 

Finally reviewing the TiKV graduation application. Mostly it looks great to me but has there been any discussion of TiKV's dependency on https://github.com/pingcap/pd? I’m not familiar with PD so I’m just raising the question of whether this is reasonable. We have plenty of projects with dependencies (e.g. on very widely used database, or k8s use of etcd before etcd came into the foundation) but I’d like some reassurance about whether PD is in the same kind of class as these, or whether there is a Plan B in the event that for some reason PD were no longer to be maintained. Thoughts welcome! 


On Mon, 3 Aug 2020 at 08:46, <tl@...> wrote:
+1, NB


Re: [VOTE] k3s for Sandbox

Matt Farina
 

I can speak to some of this...

Are we clear about sandbox projects as “not recommended for production”

The CNCF describes projects in terms of crossing the chasm. You can find that here. Sandbox is labeled as being for the innovators.

A production recommendation really depends on who you are. An enterprise is different from an early stage startup. What one would suggest be used in prod for a new startup or for The Home Depot is going to be very different. I like the description in terms of the technology adoption lifecycle instead.

The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.

This brings up a good question that, I think, is a bit more complicated. What parts of Kubernetes are required to be present to be conformant? I would leave this up to the conformance folks. For example, would the use of Virtual Kubelet (another sandbox project) be a change to mean to far to allow? Why?

From the perspective of someone deploying workloads into a cluster I don't see how it matters if the API and environment is conformant for me to run workloads in.

If I'm missing something I would be curious to know.

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

This idea isn't new. It has been brought up before. While I can't state where this sits today I do know that bringing in new ideas to k8s can be difficult now because of people working in certain ways to maintain them. In the past SIG Architecture would tell people to innovate things out of tree. If it was a good idea and proved to be useful then K8s would potentially look to bring it back in house.

I like this idea. But, I think it needs to be proved out of tree before it can be brought in.

On Mon, Aug 10, 2020, at 1:48 PM, Wise, Bob wrote:

To me, this does not feel like either of those two upstream projects. Characterizing k3s as packaging only or tooling used to manage Kubernetes is not addressing:

 

  1. The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.
  2. The precedent setting for both distros and forks.
  3. Security posture w.r.t. to the PSC and embargo issue handling. Not arguably relevant if the project stays in sandbox, but relevant to all those that follow and critical if the path is incubation-bound. Are we clear about sandbox projects as “not recommended for production”?

 

Was there a voted-on statement from the Kubernetes Steering committee on this? Were the statements made more of the “we aren’t the TOC so we don’t have standing to object”, or “wow this is awesome and we support it”?

 

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

 

-Bob

 

From: <cncf-toc@...> on behalf of Matt Farina <matt@...>
Date: Monday, August 10, 2020 at 10:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: RE: [EXTERNAL] [cncf-toc] [VOTE] k3s for Sandbox

 

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.

 

I expect there are many people in this thread that lack some context. So, I figured I'd try to add some. If someone has more to add or a correction please do so. These are intermixed with some of my personal opinions, of course.

 

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.

 

There are two things about this that jump out to me.

 

First, kind, k3s, and minikube are different in ways that are important to those who use them. Those subtle differences matter. This happens with other distros, too.

 

kind was developed with Kubernetes test infrastructure automation in mind. In fact, the docs say "kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.". Minikube, which has been around a lot longer, targets Kubernetes application developers. Their docs note, "minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit."

 

This distinction is important as we see people performing different roles. Tools for those different roles will likely look different in the end.

 

k3s targets a different group from these other two. Their docs note, "The certified Kubernetes distribution built for IoT & Edge computing". This is a different situation from the other two and I would expect the experiencing of using it to look different.

 

It may feel the same on the surface but the subtle goals are going to lead it in some different directions. Those are good as one size does not fit all.

 

Second, while minikube and kind are k8s sub-projects that doesn't mean all distros that fall under the CNCF need to be. kind you would expect to be be part of the kubernetes project because it was developed with testing kubernetes itself in mind. If minikube were started today it may have been something entirely separate from the kubernetes project. Over the years we have had discussions and debates on this theoretical topic.

 

The idea that all of these things must or should be part of the Kubernetes project doesn't fit with the discussions the k8s community has had over the years. In fact, people come to Kubernetes with ideas for changes and we regularly tell them to do them as part a different project rather than in k8s.

 

I'm surprised to see a push for distros that are open source to be part of the k8s project if they are to be in the CNCF.

 

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.

 

I would prefer to see diversity over consistency. If a distribution is conformant (we have tests for that) there should be room for diversity in the way things are done. Sometimes this will be experiments. Sometimes that will mean one distro is not consistent with another. For example, some distros ship with CRDs pre-installed which means an extended API. Sometimes that will mean someone swapped out a component with another version that uses the same APIs.

 

The sandbox is a great please to experiment in a cross company way.

 

The k8s community is amazingly busy. The people are busy. I wouldn't want to put more on their plates but rather take it off. Enabling groups to operate autonomously from each other or in a loosely coupled manner helps with that. Sub-projects of Kubernetes are limited in their ability to do that. A product of Kubernetes trying to efficiently handle the scale of people and decisions.

 

Being a separate CNCF project enables a loose coupling. It doesn't add work to an overworked k8s community but enables collaboration. This is an often overlooked element.

 

Open source projects aren't companies that fall along nice divisional lines. They are far more organic while variance in people, process, and ideas flourish. A fertile place for that is important.

 

On Mon, Aug 3, 2020, at 5:06 AM, Saad Ali via lists.cncf.io wrote:

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] k3s for Sandbox

Liz Rice
 

sandbox projects are early stage / experimental and where we want to enable neutral collaboration. There is no DD so we are not giving any recommendations (Including not recommending for production). There are no security requirements for Sandbox projects.

KSC were unequivocal about not supporting k3s as a subproject at this time, with reasons including not proliferating the number of release artifacts that k8s folks have to manage & test. That doesn't mean it's a closed door forever.

But k3s wants a neutral collaboration space for something that is clearly cloud native and an experiment with a lot of community support. I don't see any good reason not to encourage that.

Although we prefer to be consistent TOC has discretion, so accepting k3s does not force our hand for accepting future "forks" or "distros"



On Mon, 10 Aug 2020 at 18:56, Bob Wise (AWS) via lists.cncf.io <wisebob=amazon.com@...> wrote:

To me, this does not feel like either of those two upstream projects. Characterizing k3s as packaging only or tooling used to manage Kubernetes is not addressing:

 

  1. The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.
  2. The precedent setting for both distros and forks.
  3. Security posture w.r.t. to the PSC and embargo issue handling. Not arguably relevant if the project stays in sandbox, but relevant to all those that follow and critical if the path is incubation-bound. Are we clear about sandbox projects as “not recommended for production”?

 

Was there a voted-on statement from the Kubernetes Steering committee on this? Were the statements made more of the “we aren’t the TOC so we don’t have standing to object”, or “wow this is awesome and we support it”?

 

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

 

-Bob

 

From: <cncf-toc@...> on behalf of Matt Farina <matt@...>
Date: Monday, August 10, 2020 at 10:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: RE: [EXTERNAL] [cncf-toc] [VOTE] k3s for Sandbox

 

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.

 

I expect there are many people in this thread that lack some context. So, I figured I'd try to add some. If someone has more to add or a correction please do so. These are intermixed with some of my personal opinions, of course.

 

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.

 

There are two things about this that jump out to me.

 

First, kind, k3s, and minikube are different in ways that are important to those who use them. Those subtle differences matter. This happens with other distros, too.

 

kind was developed with Kubernetes test infrastructure automation in mind. In fact, the docs say "kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.". Minikube, which has been around a lot longer, targets Kubernetes application developers. Their docs note, "minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit."

 

This distinction is important as we see people performing different roles. Tools for those different roles will likely look different in the end.

 

k3s targets a different group from these other two. Their docs note, "The certified Kubernetes distribution built for IoT & Edge computing". This is a different situation from the other two and I would expect the experiencing of using it to look different.

 

It may feel the same on the surface but the subtle goals are going to lead it in some different directions. Those are good as one size does not fit all.

 

Second, while minikube and kind are k8s sub-projects that doesn't mean all distros that fall under the CNCF need to be. kind you would expect to be be part of the kubernetes project because it was developed with testing kubernetes itself in mind. If minikube were started today it may have been something entirely separate from the kubernetes project. Over the years we have had discussions and debates on this theoretical topic.

 

The idea that all of these things must or should be part of the Kubernetes project doesn't fit with the discussions the k8s community has had over the years. In fact, people come to Kubernetes with ideas for changes and we regularly tell them to do them as part a different project rather than in k8s.

 

I'm surprised to see a push for distros that are open source to be part of the k8s project if they are to be in the CNCF.

 

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.

 

I would prefer to see diversity over consistency. If a distribution is conformant (we have tests for that) there should be room for diversity in the way things are done. Sometimes this will be experiments. Sometimes that will mean one distro is not consistent with another. For example, some distros ship with CRDs pre-installed which means an extended API. Sometimes that will mean someone swapped out a component with another version that uses the same APIs.

 

The sandbox is a great please to experiment in a cross company way.

 

The k8s community is amazingly busy. The people are busy. I wouldn't want to put more on their plates but rather take it off. Enabling groups to operate autonomously from each other or in a loosely coupled manner helps with that. Sub-projects of Kubernetes are limited in their ability to do that. A product of Kubernetes trying to efficiently handle the scale of people and decisions.

 

Being a separate CNCF project enables a loose coupling. It doesn't add work to an overworked k8s community but enables collaboration. This is an often overlooked element.

 

Open source projects aren't companies that fall along nice divisional lines. They are far more organic while variance in people, process, and ideas flourish. A fertile place for that is important.

 

On Mon, Aug 3, 2020, at 5:06 AM, Saad Ali via lists.cncf.io wrote:

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] k3s for Sandbox

Bob Wise (AWS)
 

To me, this does not feel like either of those two upstream projects. Characterizing k3s as packaging only or tooling used to manage Kubernetes is not addressing:

 

  1. The forking issue, e.g. not using etcd. I believe there are other not-packaging-or-tooling related changes.
  2. The precedent setting for both distros and forks.
  3. Security posture w.r.t. to the PSC and embargo issue handling. Not arguably relevant if the project stays in sandbox, but relevant to all those that follow and critical if the path is incubation-bound. Are we clear about sandbox projects as “not recommended for production”?

 

Was there a voted-on statement from the Kubernetes Steering committee on this? Were the statements made more of the “we aren’t the TOC so we don’t have standing to object”, or “wow this is awesome and we support it”?

 

For clarity, the idea of upstream supporting multiple persistence backends in addition to etcd is a great idea – I would love to see that upstream.

 

-Bob

 

From: <cncf-toc@...> on behalf of Matt Farina <matt@...>
Date: Monday, August 10, 2020 at 10:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: RE: [EXTERNAL] [cncf-toc] [VOTE] k3s for Sandbox

 

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.

 

I expect there are many people in this thread that lack some context. So, I figured I'd try to add some. If someone has more to add or a correction please do so. These are intermixed with some of my personal opinions, of course.

 

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.

 

There are two things about this that jump out to me.

 

First, kind, k3s, and minikube are different in ways that are important to those who use them. Those subtle differences matter. This happens with other distros, too.

 

kind was developed with Kubernetes test infrastructure automation in mind. In fact, the docs say "kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.". Minikube, which has been around a lot longer, targets Kubernetes application developers. Their docs note, "minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit."

 

This distinction is important as we see people performing different roles. Tools for those different roles will likely look different in the end.

 

k3s targets a different group from these other two. Their docs note, "The certified Kubernetes distribution built for IoT & Edge computing". This is a different situation from the other two and I would expect the experiencing of using it to look different.

 

It may feel the same on the surface but the subtle goals are going to lead it in some different directions. Those are good as one size does not fit all.

 

Second, while minikube and kind are k8s sub-projects that doesn't mean all distros that fall under the CNCF need to be. kind you would expect to be be part of the kubernetes project because it was developed with testing kubernetes itself in mind. If minikube were started today it may have been something entirely separate from the kubernetes project. Over the years we have had discussions and debates on this theoretical topic.

 

The idea that all of these things must or should be part of the Kubernetes project doesn't fit with the discussions the k8s community has had over the years. In fact, people come to Kubernetes with ideas for changes and we regularly tell them to do them as part a different project rather than in k8s.

 

I'm surprised to see a push for distros that are open source to be part of the k8s project if they are to be in the CNCF.

 

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.

 

I would prefer to see diversity over consistency. If a distribution is conformant (we have tests for that) there should be room for diversity in the way things are done. Sometimes this will be experiments. Sometimes that will mean one distro is not consistent with another. For example, some distros ship with CRDs pre-installed which means an extended API. Sometimes that will mean someone swapped out a component with another version that uses the same APIs.

 

The sandbox is a great please to experiment in a cross company way.

 

The k8s community is amazingly busy. The people are busy. I wouldn't want to put more on their plates but rather take it off. Enabling groups to operate autonomously from each other or in a loosely coupled manner helps with that. Sub-projects of Kubernetes are limited in their ability to do that. A product of Kubernetes trying to efficiently handle the scale of people and decisions.

 

Being a separate CNCF project enables a loose coupling. It doesn't add work to an overworked k8s community but enables collaboration. This is an often overlooked element.

 

Open source projects aren't companies that fall along nice divisional lines. They are far more organic while variance in people, process, and ideas flourish. A fertile place for that is important.

 

On Mon, Aug 3, 2020, at 5:06 AM, Saad Ali via lists.cncf.io wrote:

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] k3s for Sandbox

Matt Farina
 

I expect there are many people in this thread that lack some context. So, I figured I'd try to add some. If someone has more to add or a correction please do so. These are intermixed with some of my personal opinions, of course.

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.

There are two things about this that jump out to me.

First, kind, k3s, and minikube are different in ways that are important to those who use them. Those subtle differences matter. This happens with other distros, too.

kind was developed with Kubernetes test infrastructure automation in mind. In fact, the docs say "kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.". Minikube, which has been around a lot longer, targets Kubernetes application developers. Their docs note, "minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit."

This distinction is important as we see people performing different roles. Tools for those different roles will likely look different in the end.

k3s targets a different group from these other two. Their docs note, "The certified Kubernetes distribution built for IoT & Edge computing". This is a different situation from the other two and I would expect the experiencing of using it to look different.

It may feel the same on the surface but the subtle goals are going to lead it in some different directions. Those are good as one size does not fit all.

Second, while minikube and kind are k8s sub-projects that doesn't mean all distros that fall under the CNCF need to be. kind you would expect to be be part of the kubernetes project because it was developed with testing kubernetes itself in mind. If minikube were started today it may have been something entirely separate from the kubernetes project. Over the years we have had discussions and debates on this theoretical topic.

The idea that all of these things must or should be part of the Kubernetes project doesn't fit with the discussions the k8s community has had over the years. In fact, people come to Kubernetes with ideas for changes and we regularly tell them to do them as part a different project rather than in k8s.

I'm surprised to see a push for distros that are open source to be part of the k8s project if they are to be in the CNCF.

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.

I would prefer to see diversity over consistency. If a distribution is conformant (we have tests for that) there should be room for diversity in the way things are done. Sometimes this will be experiments. Sometimes that will mean one distro is not consistent with another. For example, some distros ship with CRDs pre-installed which means an extended API. Sometimes that will mean someone swapped out a component with another version that uses the same APIs.

The sandbox is a great please to experiment in a cross company way.

The k8s community is amazingly busy. The people are busy. I wouldn't want to put more on their plates but rather take it off. Enabling groups to operate autonomously from each other or in a loosely coupled manner helps with that. Sub-projects of Kubernetes are limited in their ability to do that. A product of Kubernetes trying to efficiently handle the scale of people and decisions.

Being a separate CNCF project enables a loose coupling. It doesn't add work to an overworked k8s community but enables collaboration. This is an often overlooked element.

Open source projects aren't companies that fall along nice divisional lines. They are far more organic while variance in people, process, and ideas flourish. A fertile place for that is important.

On Mon, Aug 3, 2020, at 5:06 AM, Saad Ali via lists.cncf.io wrote:
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] Thanos for Incubation

Justin Cormack
 

+1 (binding)

On Mon, Jul 20, 2020 at 7:00 PM Amye Scavarda Perrin <ascavarda@...> wrote:
The Thanos project has applied for incubation: (https://github.com/cncf/toc/pull/342).

Katie Gamanji is the TOC sponsor for Thanos, and has completed due diligence.

Due diligence doc can be found here: https://docs.google.com/document/d/1jJk5seSUcgwybT4nVGOzaRGrugc90uL3WCY0fUgQh1M

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Quinton Hoole <quinton@...>
 

+100 NB.  Great!

Q

On Thu, Jul 9, 2020, 15:45 Amye Scavarda Perrin <ascavarda@...> wrote:
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] k3s for Sandbox

es Zou
 

I don't think it needs to be accepted as a sandbox project. 
1. What is the purpose of acceptance? 
2. What is the difference between it and k8s? 
Finally, sandbox should not be abused.

-1

정철 <ivy@...> 于2020年8月8日周六 上午10:59写道:


+1 non-binding

Thank you,
Acornsoft,
Alex

2020년 8월 7일 (금) 오후 11:02, Jimmy Song <jimmysong@...>님이 작성:
+1 non-binding

On Aug 7, 2020, at 1:48 PM, daxmc99 <daxmc99@...> wrote:

+1 NB


Re: [VOTE] k3s for Sandbox

정철
 


+1 non-binding

Thank you,
Acornsoft,
Alex

2020년 8월 7일 (금) 오후 11:02, Jimmy Song <jimmysong@...>님이 작성:

+1 non-binding

On Aug 7, 2020, at 1:48 PM, daxmc99 <daxmc99@...> wrote:

+1 NB


Re: [VOTE] k3s for Sandbox

Tina Tsou
 

Dear all,

 

+1, NB.

 

 

Thank you,

Tina Tsou

Enterprise Architect

Arm

tina.tsou@...

+1 (408)931-3833

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of St Leger, Jim via lists.cncf.io
Sent: Friday, August 7, 2020 3:59 PM
To: Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] k3s for Sandbox

 

+1 non-binding.

I've been on a bit of a pseudo-vacation. Not sure votes are all tallied and done (e.g. status of this vote) or still being gathered. My positive sentiment nonetheless.

Best,
Jim

 

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Amye Scavarda Perrin
Sent: Friday, July 31, 2020 8:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] k3s for Sandbox

 

k3s has applied for inclusion into the sandbox: https://github.com/cncf/toc/pull/447.

Liz Rice has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5081

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [VOTE] k3s for Sandbox

St Leger, Jim
 

+1 non-binding.

I've been on a bit of a pseudo-vacation. Not sure votes are all tallied and done (e.g. status of this vote) or still being gathered. My positive sentiment nonetheless.

Best,
Jim

 

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Amye Scavarda Perrin
Sent: Friday, July 31, 2020 8:05 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] k3s for Sandbox

 

k3s has applied for inclusion into the sandbox: https://github.com/cncf/toc/pull/447.

Liz Rice has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5081

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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

2181 - 2200 of 7337