Date   

Re: [VOTE] Kubernetes moving to graduation

Taha Ozket
 

+1 non-binding


On Tue, Mar 6, 2018 at 6:34 AM, Solomon Hykes via Lists.Cncf.Io <solomon.hykes=docker.com@...> wrote:
+1 binding

Hats off to the maintainers, sustaining this kind of growth without compromising quality and consistency of design is much harder than it looks...

On Feb 26, 2018, at 8:52 AM, Chris Aniszczyk <caniszczyk@linuxfoundation.org> wrote:

After last week's TOC call, we decided to start moving forward with graduation reviews. Kubernetes was the project that motivated the creation of the CNCF, and was its first (seed) project. It has sustained a fast pace of growth of contributors, contributing organizations, and users, and now operates at massive scale. The project's governance and community-management practices continue to evolve and mature as the project grows, but the Kubernetes Steering Committee (https://github.com/kubernetes/steeringunanimously believes that Kubernetes fulfills all the CNCF incubating and graduation criteria:

- Used successfully in production by at least three independent end users of sufficient scale and quality: https://kubernetes.io/case-studies
- Have a healthy number of committers: Kubernetes is so large, with thousands of contributors and nearly 100 repositories, that we had to develop our own mechanism to manage approval permissions. We have hundreds of approvers, listed in more than 4000 OWNERS files across the project (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+filename%3AOWNERS&type=Code)
- Demonstrate a substantial ongoing flow of commits and merged contributions: Devstats shows that we have thousands of PRs merged per month (https://k8s.devstats.cncf.io/)

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

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

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




--
Taha Ozket                                  
Senior IT Consultant taha.ozket@...

ACEDEMAND IT Consulting Services http://www.acedemand.com
Maslak Eclipse A 164 Tel: +90-212 803 0 231
Maslak / ISTANBUL Mobile: +90-532 683 43 37


Re: [VOTE] Kubernetes moving to graduation

Solomon Hykes
 

+1 binding

Hats off to the maintainers, sustaining this kind of growth without compromising quality and consistency of design is much harder than it looks...

On Feb 26, 2018, at 8:52 AM, Chris Aniszczyk <caniszczyk@...> wrote:

After last week's TOC call, we decided to start moving forward with graduation reviews. Kubernetes was the project that motivated the creation of the CNCF, and was its first (seed) project. It has sustained a fast pace of growth of contributors, contributing organizations, and users, and now operates at massive scale. The project's governance and community-management practices continue to evolve and mature as the project grows, but the Kubernetes Steering Committee (https://github.com/kubernetes/steering) unanimously believes that Kubernetes fulfills all the CNCF incubating and graduation criteria:

- Used successfully in production by at least three independent end users of sufficient scale and quality: https://kubernetes.io/case-studies
- Have a healthy number of committers: Kubernetes is so large, with thousands of contributors and nearly 100 repositories, that we had to develop our own mechanism to manage approval permissions. We have hundreds of approvers, listed in more than 4000 OWNERS files across the project (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+filename%3AOWNERS&type=Code)
- Demonstrate a substantial ongoing flow of commits and merged contributions: Devstats shows that we have thousands of PRs merged per month (https://k8s.devstats.cncf.io/)

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

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

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


TOC Agenda 3/6/2018

Chris Aniszczyk
 

Here's the agenda deck for tomorrow: https://goo.gl/LcE3TC

The formal agenda is fairly brief so there should be time for Q&A with the TOC but we will focus on an update to the TOC election due to missing a required evaluation period (see the deck), sandbox, graduation review schedule, kubernetes graduation and working group process.

Thanks!

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


Re: [VOTE] CNCF Sandbox proposal

Gou Rao <grao@...>
 

FWIW, I believe the inspiration for sandbox came from the Apache project, which uses the same term.

On Sun, Mar 4, 2018 at 12:54 PM, Bob Wise <bob@...> wrote:
As long as we are playing around with names in a non-blocking way, might I add to the list "greenhouse"?
In favor of this idea it is more aligned to selective nuturing things as they start to grow, rather than playing around and experimentation - "sandbox".

-Bob

On Sun, Mar 4, 2018 at 12:18 PM, Richard Hartmann <richih@...> wrote:
This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard






Re: [VOTE] CNCF Sandbox proposal

alexis richardson
 

Bob, All,

Thank-you all for your feedback on the Sandbox doc.

Please don't send any more new names as suggestions. While all
feedback is always welcome, I think the TOC settled on "Sandbox"
already.

We *can* share some nomenclature with other OSS foundations. That is
a Good Thing. But, sharing nomenclature does not imply that each
stage is identical. For example CNCF and ASF share "Incubation" but
use it differently. Both express an idea of relative immaturity. At
CNCF, Incubation stage is a straight up precursor for Graduation.
Incubation and Graduation let us express CNCF values and operating
principles: https://www.cncf.io/projects/graduation-criteria/ Do also
please note that maturity criteria may evolve. For example, the
number of independent maintainers has been raised as a metric for
"community". The CNCF certainly values community.

HOWEVER: If there is still confusion about the meaning of the Sandbox
stage, then let us make the document clearer.

alexis

On Mon, Mar 5, 2018 at 1:39 AM, Bob Wise <bob@bobsplanet.com> wrote:
It's a good callout, but I think it makes my point even stronger.

From https://commons.apache.org/sandbox.html

"The Sandbox is a Subversion repository for Commons committers to function
as an open workspace for sharing and collaboration."

I think we are creating confusion by calling it that. It isn't an open
workspace, it requires limited TOC support, which seems clearly intended to
nuture possible projects towards the next stage but with a lower bar. We
might ALSO need a sandbox. That seems less clear.

-Bob


On Sun, Mar 4, 2018 at 1:24 PM, Gou Rao <grao@portworx.com> wrote:

FWIW, I believe the inspiration for sandbox came from the Apache project,
which uses the same term.

On Sun, Mar 4, 2018 at 12:54 PM, Bob Wise <bob@bobsplanet.com> wrote:

As long as we are playing around with names in a non-blocking way, might
I add to the list "greenhouse"?
In favor of this idea it is more aligned to selective nuturing things as
they start to grow, rather than playing around and experimentation -
"sandbox".

-Bob

On Sun, Mar 4, 2018 at 12:18 PM, Richard Hartmann <richih@richih.org>
wrote:

This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard



Re: [VOTE] CNCF Sandbox proposal

Bob Wise
 

It's a good callout, but I think it makes my point even stronger.


"The Sandbox is a Subversion repository for Commons committers to function as an open workspace for sharing and collaboration."

I think we are creating confusion by calling it that. It isn't an open workspace, it requires limited TOC support, which seems clearly intended to nuture possible projects towards the next stage but with a lower bar. We might ALSO need a sandbox. That seems less clear.

-Bob


On Sun, Mar 4, 2018 at 1:24 PM, Gou Rao <grao@...> wrote:
FWIW, I believe the inspiration for sandbox came from the Apache project, which uses the same term.

On Sun, Mar 4, 2018 at 12:54 PM, Bob Wise <bob@...> wrote:
As long as we are playing around with names in a non-blocking way, might I add to the list "greenhouse"?
In favor of this idea it is more aligned to selective nuturing things as they start to grow, rather than playing around and experimentation - "sandbox".

-Bob

On Sun, Mar 4, 2018 at 12:18 PM, Richard Hartmann <richih@...> wrote:
This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard







Re: RexRay follow up

mueller@...
 

No worries. My recommendation is simple: don't pull in REX-Ray as a separate CNCF project. Instead allow the CSI community to decide how to best deliver the tooling necessary to make it easier for everyone to build, support and extend CSI artifacts like storage plugins, and deliver all of that under the guise of CSI. Perhaps we will decide to pull in REX-Ray to do that, as a whole or in part.

After all, the CSI itself isn't even a CNCF project yet. The community believes it's heading in that direction, though. And once that happens, it will be better for everyone if there's one stop shopping for all things CSI. Even prior to that, it's better for us in the community if we limit the number of places where CSI-related things are discussed and developed.

..Garrett


Re: [VOTE] CNCF Sandbox proposal

Bob Wise
 

As long as we are playing around with names in a non-blocking way, might I add to the list "greenhouse"?
In favor of this idea it is more aligned to selective nuturing things as they start to grow, rather than playing around and experimentation - "sandbox".

-Bob

On Sun, Mar 4, 2018 at 12:18 PM, Richard Hartmann <richih@...> wrote:
This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard





Re: [VOTE] CNCF Sandbox proposal

Michael Hausenblas <mhausenb@...>
 

+1 to "playground"


Cheers,
Michael

--
Michael Hausenblas, Developer Advocate
OpenShift by Red Hat
Mobile: +353 86 0215164 | Twitter: @mhausenblas
http://openshift.com | http://mhausenblas.info

From: Richard Hartmann <richih@...>
Reply: Richard Hartmann <richih@...>
Date: 4 March 2018 at 20:18:38
To: cncf-toc@... <cncf-toc@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject:  Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard




Re: [VOTE] CNCF Sandbox proposal

Richard Hartmann
 

This might be overly colo[u]rful, but what about playground[ or
kindergarten]? It implies no quality whatsoever, that breaking stuff
is fine and with little consequence, and clearly carries an
expectation for things to grow up before any progression.


Richard


Re: [VOTE] CNCF Sandbox proposal

alexis richardson
 

On Sun, Mar 4, 2018 at 7:26 PM, Quinton Hoole <quinton.hoole@huawei.com> wrote:
Just advocating for unambiguous communication, even to those who may not
have English as a first language.
+1 to that!



Q

From: Alexis Richardson <alexis@weave.works>
Date: Sunday, March 4, 2018 at 11:24
To: Quinton Hoole <quinton.hoole@huawei.com>
Cc: Alexis Richardson via cncf-toc <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Yes, please!

Also, you just called Chris British ;-)


On Sun, Mar 4, 2018 at 7:22 PM, Quinton Hoole <quinton.hoole@huawei.com>
wrote:

I think the proposal skirts around the due diligence issue a bit too much.
I think we need to be more direct and a little less British about it,
perhaps :). I’ll add some specific comments in the PR to clarify and offer
some constructive advice.

Q

From: <cncf-toc@lists.cncf.io> on behalf of alexis richardson
<alexis@weave.works>
Date: Sunday, March 4, 2018 at 11:17
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Cc: Alexis Richardson via cncf-toc <cncf-toc@lists.cncf.io>

Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Quinton

Thank-you. Do you think the Sandbox write-up is sufficiently clear on
that point? (I think it is, but keen to get this right).


Ruben, all,

We are intentionally lowering the bar so I am keen on "Sandbox".
IMO, secondly: we are making Sandbox somewhat qualitatively different
from Incubation, as opposed to quantitatively.

a



On Sun, Mar 4, 2018 at 7:04 PM, Quinton Hoole <quinton.hoole@huawei.com>
wrote:

While I share some of the concerns about the name sandbox (and no, I don’t
have any better proposals :-), when considering alternatives like
“launchpad” and “runway" I think that we need to be careful of overselling
the amount of due diligence that may or may not have been applied to these
projects by the CNCF. Although I like the intuitive cool and positive
appeal of these alternative names, those do carry strong connotations of
rigorous design, testing, pre-flight checks etc that occur before arriving
on a runway or launchpad, which is, I think, specifically the opposite of
what the sandbox is.

My understanding of the proposal is that the amount of technical or market
due diligence applied before acceptance is near-zero. I think we need to
state that explicitly, to set expectations correctly, and choose an
appropriate name to convey that. For all it’s flaws, “Sandbox” is accurate
in that respect.

Q

From: <cncf-toc@lists.cncf.io> on behalf of Ruben Orduz <ruben@heptio.com>
Date: Saturday, March 3, 2018 at 13:58
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Cc: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@richih.org> wrote:


On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@weave.works>
wrote:

As a co-author of this doc I want to endorse the direction as strongly
as possible. If you feel you may want to vote -1, please do so, but
ideally so that we can improve the doc.


I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard










Re: [VOTE] CNCF Sandbox proposal

Quinton Hoole
 

Aah – to be clear I was not pointing fingers at anyone in particular :-). Just advocating for unambiguous communication, even to those who may not have English as a first language.

Q

From: Alexis Richardson <alexis@...>
Date: Sunday, March 4, 2018 at 11:24
To: Quinton Hoole <quinton.hoole@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Yes, please!

Also, you just called Chris British ;-)


On Sun, Mar 4, 2018 at 7:22 PM, Quinton Hoole <quinton.hoole@...> wrote:
I think the proposal skirts around the due diligence issue a bit too much.
I think we need to be more direct and a little less British about it,
perhaps :). I’ll add some specific comments in the PR to clarify and offer
some constructive advice.

Q

From: <cncf-toc@...> on behalf of alexis richardson
Date: Sunday, March 4, 2018 at 11:17
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>

Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Quinton

Thank-you.  Do you think the Sandbox write-up is sufficiently clear on
that point?  (I think it is, but keen to get this right).


Ruben, all,

We are intentionally lowering the bar so I am keen on "Sandbox".
IMO, secondly: we are making Sandbox somewhat qualitatively different
from Incubation, as opposed to quantitatively.

a



On Sun, Mar 4, 2018 at 7:04 PM, Quinton Hoole <quinton.hoole@...>
wrote:

While I share some of the concerns about the name sandbox (and no, I don’t
have any better proposals :-), when considering alternatives like
“launchpad” and “runway" I think that we need to be careful of overselling
the amount of due diligence that may or may not have been applied to these
projects by the CNCF.  Although I like the intuitive cool and positive
appeal of these alternative names, those do carry strong connotations of
rigorous design, testing, pre-flight checks etc that occur before arriving
on a runway or launchpad, which is, I think, specifically the opposite of
what the sandbox is.

My understanding of the proposal is that the amount of technical or market
due diligence applied before acceptance is near-zero.  I think we need to
state that explicitly, to set expectations correctly, and choose an
appropriate name to convey that.  For all it’s flaws, “Sandbox” is accurate
in that respect.

Q

From: <cncf-toc@...> on behalf of Ruben Orduz <ruben@...>
Date: Saturday, March 3, 2018 at 13:58
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@...> wrote:


On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@...>
wrote:

As a co-author of this doc I want to endorse the direction as strongly
as possible.  If you feel you may want to vote -1, please do so, but
ideally so that we can improve the doc.

I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard









Re: [VOTE] CNCF Sandbox proposal

alexis richardson
 

Yes, please!

Also, you just called Chris British ;-)

On Sun, Mar 4, 2018 at 7:22 PM, Quinton Hoole <quinton.hoole@huawei.com> wrote:
I think the proposal skirts around the due diligence issue a bit too much.
I think we need to be more direct and a little less British about it,
perhaps :). I’ll add some specific comments in the PR to clarify and offer
some constructive advice.

Q

From: <cncf-toc@lists.cncf.io> on behalf of alexis richardson
<alexis@weave.works>
Date: Sunday, March 4, 2018 at 11:17
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Cc: Alexis Richardson via cncf-toc <cncf-toc@lists.cncf.io>

Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Quinton

Thank-you. Do you think the Sandbox write-up is sufficiently clear on
that point? (I think it is, but keen to get this right).


Ruben, all,

We are intentionally lowering the bar so I am keen on "Sandbox".
IMO, secondly: we are making Sandbox somewhat qualitatively different
from Incubation, as opposed to quantitatively.

a



On Sun, Mar 4, 2018 at 7:04 PM, Quinton Hoole <quinton.hoole@huawei.com>
wrote:

While I share some of the concerns about the name sandbox (and no, I don’t
have any better proposals :-), when considering alternatives like
“launchpad” and “runway" I think that we need to be careful of overselling
the amount of due diligence that may or may not have been applied to these
projects by the CNCF. Although I like the intuitive cool and positive
appeal of these alternative names, those do carry strong connotations of
rigorous design, testing, pre-flight checks etc that occur before arriving
on a runway or launchpad, which is, I think, specifically the opposite of
what the sandbox is.

My understanding of the proposal is that the amount of technical or market
due diligence applied before acceptance is near-zero. I think we need to
state that explicitly, to set expectations correctly, and choose an
appropriate name to convey that. For all it’s flaws, “Sandbox” is accurate
in that respect.

Q

From: <cncf-toc@lists.cncf.io> on behalf of Ruben Orduz <ruben@heptio.com>
Date: Saturday, March 3, 2018 at 13:58
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Cc: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@richih.org> wrote:


On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@weave.works>
wrote:

As a co-author of this doc I want to endorse the direction as strongly
as possible. If you feel you may want to vote -1, please do so, but
ideally so that we can improve the doc.
I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard








Re: [VOTE] CNCF Sandbox proposal

Quinton Hoole
 

I think the proposal skirts around the due diligence issue a bit too much.  I think we need to be more direct and a little less British about it, perhaps :). I’ll add some specific comments in the PR to clarify and offer some constructive advice.

Q

From: <cncf-toc@...> on behalf of alexis richardson <alexis@...>
Date: Sunday, March 4, 2018 at 11:17
To: "cncf-toc@..." <cncf-toc@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

Quinton

Thank-you.  Do you think the Sandbox write-up is sufficiently clear on
that point?  (I think it is, but keen to get this right).


Ruben, all,

We are intentionally lowering the bar so I am keen on "Sandbox".
IMO, secondly: we are making Sandbox somewhat qualitatively different
from Incubation, as opposed to quantitatively.

a



On Sun, Mar 4, 2018 at 7:04 PM, Quinton Hoole <quinton.hoole@...> wrote:
While I share some of the concerns about the name sandbox (and no, I don’t
have any better proposals :-), when considering alternatives like
“launchpad” and “runway" I think that we need to be careful of overselling
the amount of due diligence that may or may not have been applied to these
projects by the CNCF.  Although I like the intuitive cool and positive
appeal of these alternative names, those do carry strong connotations of
rigorous design, testing, pre-flight checks etc that occur before arriving
on a runway or launchpad, which is, I think, specifically the opposite of
what the sandbox is.

My understanding of the proposal is that the amount of technical or market
due diligence applied before acceptance is near-zero.  I think we need to
state that explicitly, to set expectations correctly, and choose an
appropriate name to convey that.  For all it’s flaws, “Sandbox” is accurate
in that respect.

Q

From: <cncf-toc@...> on behalf of Ruben Orduz <ruben@...>
Date: Saturday, March 3, 2018 at 13:58
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@...> wrote:

On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@...>
wrote:

> As a co-author of this doc I want to endorse the direction as strongly
> as possible.  If you feel you may want to vote -1, please do so, but
> ideally so that we can improve the doc.

I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard








Re: [VOTE] CNCF Sandbox proposal

alexis richardson
 

Quinton

Thank-you. Do you think the Sandbox write-up is sufficiently clear on
that point? (I think it is, but keen to get this right).


Ruben, all,

We are intentionally lowering the bar so I am keen on "Sandbox".
IMO, secondly: we are making Sandbox somewhat qualitatively different
from Incubation, as opposed to quantitatively.

a

On Sun, Mar 4, 2018 at 7:04 PM, Quinton Hoole <quinton.hoole@huawei.com> wrote:
While I share some of the concerns about the name sandbox (and no, I don’t
have any better proposals :-), when considering alternatives like
“launchpad” and “runway" I think that we need to be careful of overselling
the amount of due diligence that may or may not have been applied to these
projects by the CNCF. Although I like the intuitive cool and positive
appeal of these alternative names, those do carry strong connotations of
rigorous design, testing, pre-flight checks etc that occur before arriving
on a runway or launchpad, which is, I think, specifically the opposite of
what the sandbox is.

My understanding of the proposal is that the amount of technical or market
due diligence applied before acceptance is near-zero. I think we need to
state that explicitly, to set expectations correctly, and choose an
appropriate name to convey that. For all it’s flaws, “Sandbox” is accurate
in that respect.

Q

From: <cncf-toc@lists.cncf.io> on behalf of Ruben Orduz <ruben@heptio.com>
Date: Saturday, March 3, 2018 at 13:58
To: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Cc: "cncf-toc@lists.cncf.io" <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@richih.org> wrote:

On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@weave.works>
wrote:

As a co-author of this doc I want to endorse the direction as strongly
as possible. If you feel you may want to vote -1, please do so, but
ideally so that we can improve the doc.
I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard



Re: [VOTE] CNCF Sandbox proposal

Quinton Hoole
 

While I share some of the concerns about the name sandbox (and no, I don’t have any better proposals :-), when considering alternatives like “launchpad” and “runway" I think that we need to be careful of overselling the amount of due diligence that may or may not have been applied to these projects by the CNCF.  Although I like the intuitive cool and positive appeal of these alternative names, those do carry strong connotations of rigorous design, testing, pre-flight checks etc that occur before arriving on a runway or launchpad, which is, I think, specifically the opposite of what the sandbox is.

My understanding of the proposal is that the amount of technical or market due diligence applied before acceptance is near-zero.  I think we need to state that explicitly, to set expectations correctly, and choose an appropriate name to convey that.  For all it’s flaws, “Sandbox” is accurate in that respect. 

Q

From: <cncf-toc@...> on behalf of Ruben Orduz <ruben@...>
Date: Saturday, March 3, 2018 at 13:58
To: "cncf-toc@..." <cncf-toc@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] CNCF Sandbox proposal

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@...> wrote:
On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@...> wrote:

> As a co-author of this doc I want to endorse the direction as strongly
> as possible.  If you feel you may want to vote -1, please do so, but
> ideally so that we can improve the doc.

I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard





Re: RexRay follow up

alexis richardson
 

Garrett,

Forgive me, I am not quite sure I follow.  What is your recommendation for rexray in the context of your description below?

A


On Sun, 4 Mar 2018, 15:18 Mueller, Garrett, <Garrett.Mueller@...> wrote:
If I’m taking your meaning correctly, co-evolution (where there are two independent projects that rely on each other) is precisely the situation I was arguing against.

If we do this right, I think there should be three things. CSI itself, orchestrator implementations of CSI, and CSI storage plugins. Each of those three things already co-evolve somewhat independently. Many of us are already working on all three.

A project that helps people write CSI things shouldn’t be a 4th thing, in my opinion. It should be something the CSI community creates and evolves together based directly on the spec that it’s writing.

Thanks,
..Garrett
Technical Director @ NetApp

From: cncf-toc@... <cncf-toc@...> on behalf of alexis richardson <alexis@...>
Sent: Saturday, March 3, 2018 2:57:24 AM
To: cncf-toc@...
Cc: cncf-toc@...

Subject: Re: [cncf-toc] RexRay follow up
If rexray and CSI benefit from "co evolution" then that might make sense.  Is that the case?  What does the community think?

On Sat, 3 Mar 2018, 05:05 Bassam Tabbara, <bassam@...> wrote:
Thanks Dan, I think having spec and implementation(s) in the same foundation make sense.

In this case, Rex-Ray is not an implementation. If I understood it correctly, its a  a set of tools, packaging, and libraries that aid in writing CSI plugins. So it feels a bit different.

It almost like saying there is OpenTracing, OpenTracing-Packaging-and-Tools, and Jaeger as three separate projects.

I think it would make more sense to make Rex-Ray part of CSI if the two communities are open to that. 

On Mar 2, 2018, at 4:48 PM, Dan Kohn <dan@...> wrote:

CNCF has three precedents of separate specs and implementations:

+ CNI and the CNI plugins (most prominently Calico, Flannel and Weave Net, none of which are yet CNCF projects)
+ OpenTracing and Jaeger
+ TUF and Notary

So, the example of CSI as the spec and REX-Ray as an implementation seems feasible. Whether it is advisable is, of course, up to the TOC.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Fri, Mar 2, 2018 at 5:36 PM, Mueller, Garrett <Garrett.Mueller@...> wrote:

I see where you’re coming from Clint, but in this case I agree with Bassam. To follow on to what he said, I’m very concerned that this would become yet another place where the interface to storage would need to be discussed, and I think that’s a really bad move right now.

 

As a community, we already have at least three different regular storage meetings: the CNCF storage WG, the k8s storage-sig and CSI. You have to track at least those to maintain even a basic idea of what’s going on. And if you really want to be involved with k8s, there’s already a lot more than that to deal with. As the other orchestrators become more CSI aware, there will likely be storage meetings for each of them as well.

 

And the line between the orchestrators and the CSI moves all the time. For about a year we’ve been talking about snapshots in k8s, and in just the past week there’s been discussion about moving that into CSI itself. If we make that move it isn’t just done on paper, it has a material change on interfaces and how it needs to be implemented.

 

Adding another thing in the mix in-between makes the lines more blurry than they already are, and an already difficult problem untenable.

 

For this reason, I think the CSI needs to re-consider its “spec only” stance and provide some basic enablement as well as mechanisms that make it easy for different people to experiment in and around it instead. Each orchestrator is going to have its CSI implementation to deal with too. Please, no more! :)

 

..Garrett

Technical Director @ NetApp

https://netapp.io/

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Kitson, Clinton
Sent: Friday, March 2, 2018 12:28 PM
To: cncf-toc@...


Subject: Re: [cncf-toc] RexRay follow up

 

https://docs.google.com/presentation/d/1BthkP9OftIICEn1h9ML1F0TKXhaUxXILlcDpuz3Sjzg/edit#slide=id.g31eff88140_0_37

 

The best place to start here is to refer to the slide above. CSI by its name is an interface specification. It has always been the intent of the group to keep it CO agnostic and focused on the key primitives that will enable volume storage. CSI tackles the fragmentation problem of a single spec to implement. But there are many other aspects to creating a production grade plugins that up to this point has intentionally been avoided in the CSI spec. So for this I think a implementation framework for the storage eco-system to work together on will be important to the other aspects of our fragmentation problem. REX-Ray is this framework for CSI, abstract of storage platform, that will 1) CO centric deployment and documentation 2) a great user experience from common packaging, docs, configuration which is important to operators and trusting CSI 3) be a placeholder for proving functionality that may or may not eventually end up in the CSI spec. 

 

 

 

Clint Kitson

Technical Director for {code}

CNCF Governing Board Member

--- 

mobile: "+1 424 645 4116"

twitter: "@clintkitson"


From: cncf-toc@... [cncf-toc@...] on behalf of Gou Rao [grao@...]
Sent: Thursday, March 1, 2018 10:21 AM
To: 
cncf-toc@...
Cc: CNCF TOC
Subject: Re: [cncf-toc] RexRay follow up

I think Clint should chime in here, but I had seen RexRay as more than just a CSI implementation... as a multi platform storage orchestrator?  Maybe some clarification on what that means could help, but for example, with Mesosphere, we use frameworks for complex stateful applications (take Cassandra for example).  Would RexRay help orchestrate storage provisioning (via CSI) to a framework like that?

 

On Thu, Mar 1, 2018 at 9:59 AM, alexis richardson <alexis@...> wrote:

Yes I think so.  But really I am a storage idiot. Who else could we ask?

 

On Thu, 1 Mar 2018, 17:53 Bassam Tabbara, <bassam@...> wrote:

I’m glad to see the strong alignment between Rex-Ray and CSI.

 

Would it make sense for Rex-Ray to be even more closely aligned with CSI, i.e. as a set of libraries and tools for people wanting to build CSI implementations. For example, CSI has a placeholder repo (see https://github.com/container-storage-interface/libraries) for libraries and tools. Similar to the Kubernetes incubator repo. Could RexRay become part of that or does it need to be its own top-level project?

 

I worry about confusing developers and end-users with another CNCF project that attempt to achieve the same goal — CSI.

On Mar 1, 2018, at 8:48 AM, alexis richardson <alexis@...> wrote:

 

All - questions?

(thanks Clint, this is super helpful)


On Tue, Feb 20, 2018 at 6:00 PM, Kitson, Clinton
<
clinton.kitson@...> wrote:


Correct Brian, REX-Ray should be transparent to end users in this space and
provides an important service by helping connect apps to storage. Operators
of clusters are the ones that should be very aware of it as it would provide
trusted and more quality plugins that are built on top of the existing CSI
spec.

REX-Ray stats: Recently REX-Ray went through some refactoring to accommodate
the CSI architecture changes that needed to take place. This meant rolling
in the libStorage functionality which unfortunately skews the numbers a bit.
The {code} team has been primary maintainers on the framework where
collaborators have mainly focused on building drivers. Other storage
companies who understand the complexity involved in building a solid CSI
implementation see the value and commonality that can be addressed by
REX-Ray and are interested in collaborating if supported via a foundation.

Production users: Yes, REX-Ray is being used in production by some of the
users listed in the slides. Up to this point, usage levels have been tied
closely to production deployment of Mesos & Docker.

Sandbox: I believe the numbers and history justify incubation, but we can
discuss it.

Control plane: REX-Ray used to have its own control plane (libStorage API)
prior to CSI. In most recent we have made architectural changes to be adhere
to CSI.  When libStorage was its control-plane, there was integration work
performed to make libStorage a volume plugin and additionally to Cloud
Foundry. Today, anyone who implements CSI on the cluster orchestrator side
can talk with any REX-Ray plugin.

Data plane: REX-Ray is not involved in the data-plane of storage operations.
It is an orchestrator and simply gets two components (local/remote storage &
an OS) connected. It essentially performs the exact same steps that someone
would manually perform to get these two components communicating and the
reverse on tear down.

Persistent state: It is completely stateless today.




Clint Kitson
Technical Director for {code}
CNCF Governing Board Member
---
email: Clinton.Kitson@...
mobile: "
+1 424 645 4116"
team: theCodeTeam.com
twitter: "@clintkitson"
github: 
github.com/clintkitson



 

 







Re: RexRay follow up

Mueller, Garrett <Garrett.Mueller@...>
 

If I’m taking your meaning correctly, co-evolution (where there are two independent projects that rely on each other) is precisely the situation I was arguing against.

If we do this right, I think there should be three things. CSI itself, orchestrator implementations of CSI, and CSI storage plugins. Each of those three things already co-evolve somewhat independently. Many of us are already working on all three.

A project that helps people write CSI things shouldn’t be a 4th thing, in my opinion. It should be something the CSI community creates and evolves together based directly on the spec that it’s writing.

Thanks,
..Garrett
Technical Director @ NetApp
https://netapp.io


From: cncf-toc@... <cncf-toc@...> on behalf of alexis richardson <alexis@...>
Sent: Saturday, March 3, 2018 2:57:24 AM
To: cncf-toc@...
Cc: cncf-toc@...
Subject: Re: [cncf-toc] RexRay follow up
 
If rexray and CSI benefit from "co evolution" then that might make sense.  Is that the case?  What does the community think?

On Sat, 3 Mar 2018, 05:05 Bassam Tabbara, <bassam@...> wrote:
Thanks Dan, I think having spec and implementation(s) in the same foundation make sense.

In this case, Rex-Ray is not an implementation. If I understood it correctly, its a  a set of tools, packaging, and libraries that aid in writing CSI plugins. So it feels a bit different.

It almost like saying there is OpenTracing, OpenTracing-Packaging-and-Tools, and Jaeger as three separate projects.

I think it would make more sense to make Rex-Ray part of CSI if the two communities are open to that. 

On Mar 2, 2018, at 4:48 PM, Dan Kohn <dan@...> wrote:

CNCF has three precedents of separate specs and implementations:

+ CNI and the CNI plugins (most prominently Calico, Flannel and Weave Net, none of which are yet CNCF projects)
+ OpenTracing and Jaeger
+ TUF and Notary

So, the example of CSI as the spec and REX-Ray as an implementation seems feasible. Whether it is advisable is, of course, up to the TOC.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Fri, Mar 2, 2018 at 5:36 PM, Mueller, Garrett <Garrett.Mueller@...> wrote:

I see where you’re coming from Clint, but in this case I agree with Bassam. To follow on to what he said, I’m very concerned that this would become yet another place where the interface to storage would need to be discussed, and I think that’s a really bad move right now.

 

As a community, we already have at least three different regular storage meetings: the CNCF storage WG, the k8s storage-sig and CSI. You have to track at least those to maintain even a basic idea of what’s going on. And if you really want to be involved with k8s, there’s already a lot more than that to deal with. As the other orchestrators become more CSI aware, there will likely be storage meetings for each of them as well.

 

And the line between the orchestrators and the CSI moves all the time. For about a year we’ve been talking about snapshots in k8s, and in just the past week there’s been discussion about moving that into CSI itself. If we make that move it isn’t just done on paper, it has a material change on interfaces and how it needs to be implemented.

 

Adding another thing in the mix in-between makes the lines more blurry than they already are, and an already difficult problem untenable.

 

For this reason, I think the CSI needs to re-consider its “spec only” stance and provide some basic enablement as well as mechanisms that make it easy for different people to experiment in and around it instead. Each orchestrator is going to have its CSI implementation to deal with too. Please, no more! :)

 

..Garrett

Technical Director @ NetApp

https://netapp.io/

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Kitson, Clinton
Sent: Friday, March 2, 2018 12:28 PM
To: cncf-toc@...


Subject: Re: [cncf-toc] RexRay follow up

 

https://docs.google.com/presentation/d/1BthkP9OftIICEn1h9ML1F0TKXhaUxXILlcDpuz3Sjzg/edit#slide=id.g31eff88140_0_37

 

The best place to start here is to refer to the slide above. CSI by its name is an interface specification. It has always been the intent of the group to keep it CO agnostic and focused on the key primitives that will enable volume storage. CSI tackles the fragmentation problem of a single spec to implement. But there are many other aspects to creating a production grade plugins that up to this point has intentionally been avoided in the CSI spec. So for this I think a implementation framework for the storage eco-system to work together on will be important to the other aspects of our fragmentation problem. REX-Ray is this framework for CSI, abstract of storage platform, that will 1) CO centric deployment and documentation 2) a great user experience from common packaging, docs, configuration which is important to operators and trusting CSI 3) be a placeholder for proving functionality that may or may not eventually end up in the CSI spec. 

 

 

 

Clint Kitson

Technical Director for {code}

CNCF Governing Board Member

--- 

mobile: "+1 424 645 4116"

twitter: "@clintkitson"


From: cncf-toc@... [cncf-toc@...] on behalf of Gou Rao [grao@...]
Sent: Thursday, March 1, 2018 10:21 AM
To: 
cncf-toc@...
Cc: CNCF TOC
Subject: Re: [cncf-toc] RexRay follow up

I think Clint should chime in here, but I had seen RexRay as more than just a CSI implementation... as a multi platform storage orchestrator?  Maybe some clarification on what that means could help, but for example, with Mesosphere, we use frameworks for complex stateful applications (take Cassandra for example).  Would RexRay help orchestrate storage provisioning (via CSI) to a framework like that?

 

On Thu, Mar 1, 2018 at 9:59 AM, alexis richardson <alexis@...> wrote:

Yes I think so.  But really I am a storage idiot. Who else could we ask?

 

On Thu, 1 Mar 2018, 17:53 Bassam Tabbara, <bassam@...> wrote:

I’m glad to see the strong alignment between Rex-Ray and CSI.

 

Would it make sense for Rex-Ray to be even more closely aligned with CSI, i.e. as a set of libraries and tools for people wanting to build CSI implementations. For example, CSI has a placeholder repo (see https://github.com/container-storage-interface/libraries) for libraries and tools. Similar to the Kubernetes incubator repo. Could RexRay become part of that or does it need to be its own top-level project?

 

I worry about confusing developers and end-users with another CNCF project that attempt to achieve the same goal — CSI.

On Mar 1, 2018, at 8:48 AM, alexis richardson <alexis@...> wrote:

 

All - questions?

(thanks Clint, this is super helpful)


On Tue, Feb 20, 2018 at 6:00 PM, Kitson, Clinton
<
clinton.kitson@...> wrote:


Correct Brian, REX-Ray should be transparent to end users in this space and
provides an important service by helping connect apps to storage. Operators
of clusters are the ones that should be very aware of it as it would provide
trusted and more quality plugins that are built on top of the existing CSI
spec.

REX-Ray stats: Recently REX-Ray went through some refactoring to accommodate
the CSI architecture changes that needed to take place. This meant rolling
in the libStorage functionality which unfortunately skews the numbers a bit.
The {code} team has been primary maintainers on the framework where
collaborators have mainly focused on building drivers. Other storage
companies who understand the complexity involved in building a solid CSI
implementation see the value and commonality that can be addressed by
REX-Ray and are interested in collaborating if supported via a foundation.

Production users: Yes, REX-Ray is being used in production by some of the
users listed in the slides. Up to this point, usage levels have been tied
closely to production deployment of Mesos & Docker.

Sandbox: I believe the numbers and history justify incubation, but we can
discuss it.

Control plane: REX-Ray used to have its own control plane (libStorage API)
prior to CSI. In most recent we have made architectural changes to be adhere
to CSI.  When libStorage was its control-plane, there was integration work
performed to make libStorage a volume plugin and additionally to Cloud
Foundry. Today, anyone who implements CSI on the cluster orchestrator side
can talk with any REX-Ray plugin.

Data plane: REX-Ray is not involved in the data-plane of storage operations.
It is an orchestrator and simply gets two components (local/remote storage &
an OS) connected. It essentially performs the exact same steps that someone
would manually perform to get these two components communicating and the
reverse on tear down.

Persistent state: It is completely stateless today.




Clint Kitson
Technical Director for {code}
CNCF Governing Board Member
---
email: Clinton.Kitson@...
mobile: "
+1 424 645 4116"
team: theCodeTeam.com
twitter: "@clintkitson"
github: 
github.com/clintkitson



 

 







Re: [VOTE] CNCF Sandbox proposal

Ruben Orduz <ruben@...>
 

FWIW, two ideas I've fiddled with recently: Launchpad or Runway

On Sat, Mar 3, 2018 at 4:45 PM, Richard Hartmann <richih@...> wrote:
On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@...> wrote:

> As a co-author of this doc I want to endorse the direction as strongly
> as possible.  If you feel you may want to vote -1, please do so, but
> ideally so that we can improve the doc.

I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard





Re: [VOTE] CNCF Sandbox proposal

alexis richardson
 

Thank-you Richard, appreciate the thought that you and others have put into it.

On Sat, Mar 3, 2018 at 9:45 PM, Richard Hartmann <richih@richih.org> wrote:
On Thu, Mar 1, 2018 at 4:04 PM, alexis richardson <alexis@weave.works> wrote:

As a co-author of this doc I want to endorse the direction as strongly
as possible. If you feel you may want to vote -1, please do so, but
ideally so that we can improve the doc.
I think it's a good direction to take.

As per the discussion in the doc, the name has connotations which are
contrary to the intended meaning. That being said, I couldn't come up
with a better name; back then or in the last two days; neither could
others.


Long story short: No need to block on this; the improved process far
outweighs any potential naming confusion.


Richard


4701 - 4720 of 6536