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

What do you not like about the name, and what other name would you prefer?

On Wed, Feb 28, 2018 at 11:13 AM, Richard Hartmann <richih@...> wrote:

On Wed, Feb 28, 2018 at 7:46 PM, Ruben Orduz <ruben@...> wrote:
> +1 non-biding on the spirit, -1 non-binding on the naming.

Same.

There’s been a desire within the CNCF TOC and community to provide further clarity around project maturity levels in CNCF and this has resulted into the CNCF Sandbox proposal after a month of discussion: https://github.com/cncf/toc/pull/92

When we initially created the Inception project level, it was intended to provide an avenue for technically interesting early-stage projects that were beneficial to the cloud-native community. We are transitioning Inception projects to the Sandbox. When we say that Sandbox projects are "early stage" this covers the following examples:

- New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. In the case of Kubernetes, the Sandbox is intended as a home for projects that would previously have started in the Kubernetes Incubator.

- Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need)

- Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects

- Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that

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

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support! Note, if the proposal passes, CNCF staff will make updates to website and all other marketing collateral regarding this change.

--

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

Archiving means that the project is no longer supported by CNCF (for whatever reason, TOC is empowered to make that decision), similar to how the Apache Attic works or Eclipse Foundation archiving process.

I'll reply to your comment on GitHub but an action item would be to define the archiving process as we haven't had to use it yet.

On Thu, Mar 1, 2018 at 9:42 AM, Justin Cormack via Lists.Cncf.Io <justin.cormack=docker.com@lists.cncf.io> wrote:

I have an outstanding query on the text around archiving and exit

https://github.com/cncf/toc/pull/92#pullrequestreview-99852558

And there is another issue open.

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

+1, binding

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.

Keep voting, people, please!

On Thu, Mar 1, 2018 at 2:58 PM, Sebastien Goasguen <sebgoa@...> wrote:
> +1 (non-binding)
>
> On Thu, Mar 1, 2018 at 3:55 PM, Camille Fournier <skamille@...> wrote:
>>
>> +1 binding
>>
>> On Wed, Feb 28, 2018 at 1:42 PM, Chris Aniszczyk
>> <caniszczyk@...g> wrote:
>>>
>>> There’s been a desire within the CNCF TOC and community to provide
>>> further clarity around project maturity levels in CNCF and this has resulted
>>> into the CNCF Sandbox proposal after a month of discussion:
>>> https://github.com/cncf/toc/pull/92
>>>
>>> When we initially created the Inception project level, it was intended to
>>> provide an avenue for technically interesting early-stage projects that were
>>> beneficial to the cloud-native community. We are transitioning Inception
>>> projects to the Sandbox. When we say that Sandbox projects are "early stage"
>>> this covers the following examples:
>>>
>>> - New projects that are designed to extend one or more CNCF projects with
>>> functionality or interoperability libraries. In the case of Kubernetes, the
>>> Sandbox is intended as a home for projects that would previously have
>>> started in the Kubernetes Incubator.
>>> - Independent projects that fit the CNCF mission and provide potential
>>> for a novel approach to existing functional areas (or are an attempt to meet
>>> an unfulfilled need)
>>> - Projects commissioned or sanctioned by the CNCF, including initial code
>>> for CNCF WG collaborations, and "experimental" projects
>>> - Any project that realistically intends to join CNCF Incubation in
>>> future and wishes to lay the foundations for that
>>>
>>> Please vote (+1/0/-1) by replying to this thread; the full proposal
>>> located here: https://github.com/cncf/toc/pull/92
>>>
>>> Remember that the TOC has binding votes only, but we do appreciate
>>> non-binding votes from the community as a sign of support! Note, if the
>>> proposal passes, CNCF staff will make updates to website and all other
>>> marketing collateral regarding this change.
>>>
>>> --
>>> Chris Aniszczyk (@cra) | +1-512-961-6719
>>
>>
>
>
>
> --
>
> Sebastien Goasguen
>
> Senior Director of Cloud Technologies, Bitnami
>
> +41 79 367 38 25
>
> @sebgoa
>
>

--

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

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

+1, binding

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.

Also, if you do have comments/suggestions on details, please comment on the PR (and thanks to Justin Cormack, who has done so):

https://github.com/cncf/toc/pull/92

 

Keep voting, people, please!

On Thu, Mar 1, 2018 at 2:58 PM, Sebastien Goasguen <sebgoa@...> wrote:
> +1 (non-binding)
>
> On Thu, Mar 1, 2018 at 3:55 PM, Camille Fournier <skamille@...> wrote:
>>
>> +1 binding
>>
>> On Wed, Feb 28, 2018 at 1:42 PM, Chris Aniszczyk
>> <caniszczyk@...g> wrote:
>>>
>>> There’s been a desire within the CNCF TOC and community to provide
>>> further clarity around project maturity levels in CNCF and this has resulted
>>> into the CNCF Sandbox proposal after a month of discussion:
>>> https://github.com/cncf/toc/pull/92
>>>
>>> When we initially created the Inception project level, it was intended to
>>> provide an avenue for technically interesting early-stage projects that were
>>> beneficial to the cloud-native community. We are transitioning Inception
>>> projects to the Sandbox. When we say that Sandbox projects are "early stage"
>>> this covers the following examples:
>>>
>>> - New projects that are designed to extend one or more CNCF projects with
>>> functionality or interoperability libraries. In the case of Kubernetes, the
>>> Sandbox is intended as a home for projects that would previously have
>>> started in the Kubernetes Incubator.
>>> - Independent projects that fit the CNCF mission and provide potential
>>> for a novel approach to existing functional areas (or are an attempt to meet
>>> an unfulfilled need)
>>> - Projects commissioned or sanctioned by the CNCF, including initial code
>>> for CNCF WG collaborations, and "experimental" projects
>>> - Any project that realistically intends to join CNCF Incubation in
>>> future and wishes to lay the foundations for that
>>>
>>> Please vote (+1/0/-1) by replying to this thread; the full proposal
>>> located here: https://github.com/cncf/toc/pull/92
>>>
>>> Remember that the TOC has binding votes only, but we do appreciate
>>> non-binding votes from the community as a sign of support! Note, if the
>>> proposal passes, CNCF staff will make updates to website and all other
>>> marketing collateral regarding this change.
>>>
>>> --
>>> Chris Aniszczyk (@cra) | +1-512-961-6719
>>
>>
>
>
>
> --
>
> Sebastien Goasguen
>
> Senior Director of Cloud Technologies, Bitnami
>
> +41 79 367 38 25
>
> @sebgoa
>
>

+1, binding

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.

Keep voting, people, please!

On Thu, Mar 1, 2018 at 2:58 PM, Sebastien Goasguen <sebgoa@...> wrote:
> +1 (non-binding)
>
> On Thu, Mar 1, 2018 at 3:55 PM, Camille Fournier <skamille@...> wrote:
>>
>> +1 binding
>>
>> On Wed, Feb 28, 2018 at 1:42 PM, Chris Aniszczyk
>> <caniszczyk@linuxfoundation.org> wrote:
>>>
>>> There’s been a desire within the CNCF TOC and community to provide
>>> further clarity around project maturity levels in CNCF and this has resulted
>>> into the CNCF Sandbox proposal after a month of discussion:
>>> https://github.com/cncf/toc/pull/92
>>>
>>> When we initially created the Inception project level, it was intended to
>>> provide an avenue for technically interesting early-stage projects that were
>>> beneficial to the cloud-native community. We are transitioning Inception
>>> projects to the Sandbox. When we say that Sandbox projects are "early stage"
>>> this covers the following examples:
>>>
>>> - New projects that are designed to extend one or more CNCF projects with
>>> functionality or interoperability libraries. In the case of Kubernetes, the
>>> Sandbox is intended as a home for projects that would previously have
>>> started in the Kubernetes Incubator.
>>> - Independent projects that fit the CNCF mission and provide potential
>>> for a novel approach to existing functional areas (or are an attempt to meet
>>> an unfulfilled need)
>>> - Projects commissioned or sanctioned by the CNCF, including initial code
>>> for CNCF WG collaborations, and "experimental" projects
>>> - Any project that realistically intends to join CNCF Incubation in
>>> future and wishes to lay the foundations for that
>>>
>>> Please vote (+1/0/-1) by replying to this thread; the full proposal
>>> located here: https://github.com/cncf/toc/pull/92
>>>
>>> Remember that the TOC has binding votes only, but we do appreciate
>>> non-binding votes from the community as a sign of support! Note, if the
>>> proposal passes, CNCF staff will make updates to website and all other
>>> marketing collateral regarding this change.
>>>
>>> --
>>> Chris Aniszczyk (@cra) | +1-512-961-6719
>>
>>
>
>
>
> --
>
> Sebastien Goasguen
>
> Senior Director of Cloud Technologies, Bitnami
>
> +41 79 367 38 25
>
> @sebgoa
>
>

+1, binding

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.

Keep voting, people, please!

On Thu, Mar 1, 2018 at 2:58 PM, Sebastien Goasguen <sebgoa@...> wrote:
> +1 (non-binding)
>
> On Thu, Mar 1, 2018 at 3:55 PM, Camille Fournier <skamille@...> wrote:
>>
>> +1 binding
>>
>> On Wed, Feb 28, 2018 at 1:42 PM, Chris Aniszczyk
>> <caniszczyk@linuxfoundation.org> wrote:
>>>
>>> There’s been a desire within the CNCF TOC and community to provide
>>> further clarity around project maturity levels in CNCF and this has resulted
>>> into the CNCF Sandbox proposal after a month of discussion:
>>> https://github.com/cncf/toc/pull/92
>>>
>>> When we initially created the Inception project level, it was intended to
>>> provide an avenue for technically interesting early-stage projects that were
>>> beneficial to the cloud-native community. We are transitioning Inception
>>> projects to the Sandbox. When we say that Sandbox projects are "early stage"
>>> this covers the following examples:
>>>
>>> - New projects that are designed to extend one or more CNCF projects with
>>> functionality or interoperability libraries. In the case of Kubernetes, the
>>> Sandbox is intended as a home for projects that would previously have
>>> started in the Kubernetes Incubator.
>>> - Independent projects that fit the CNCF mission and provide potential
>>> for a novel approach to existing functional areas (or are an attempt to meet
>>> an unfulfilled need)
>>> - Projects commissioned or sanctioned by the CNCF, including initial code
>>> for CNCF WG collaborations, and "experimental" projects
>>> - Any project that realistically intends to join CNCF Incubation in
>>> future and wishes to lay the foundations for that
>>>
>>> Please vote (+1/0/-1) by replying to this thread; the full proposal
>>> located here: https://github.com/cncf/toc/pull/92
>>>
>>> Remember that the TOC has binding votes only, but we do appreciate
>>> non-binding votes from the community as a sign of support! Note, if the
>>> proposal passes, CNCF staff will make updates to website and all other
>>> marketing collateral regarding this change.
>>>
>>> --
>>> Chris Aniszczyk (@cra) | +1-512-961-6719
>>
>>
>
>
>
> --
>
> Sebastien Goasguen
>
> Senior Director of Cloud Technologies, Bitnami
>
> +41 79 367 38 25
>
> @sebgoa
>
>

There’s been a desire within the CNCF TOC and community to provide further clarity around project maturity levels in CNCF and this has resulted into the CNCF Sandbox proposal after a month of discussion: https://github.com/cncf/toc/pull/92

When we initially created the Inception project level, it was intended to provide an avenue for technically interesting early-stage projects that were beneficial to the cloud-native community. We are transitioning Inception projects to the Sandbox. When we say that Sandbox projects are "early stage" this covers the following examples:

- New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. In the case of Kubernetes, the Sandbox is intended as a home for projects that would previously have started in the Kubernetes Incubator.

- Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need)

- Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects

- Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that

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

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support! Note, if the proposal passes, CNCF staff will make updates to website and all other marketing collateral regarding this change.

--

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

On Wed, Feb 28, 2018 at 7:46 PM, Ruben Orduz <ruben@...> wrote:
> +1 non-biding on the spirit, -1 non-binding on the naming.

Same.

+1 binding

On Wed, Feb 28, 2018 at 1:42 PM, Chris Aniszczyk <caniszczyk@linuxfoundation.org> wrote:

There’s been a desire within the CNCF TOC and community to provide further clarity around project maturity levels in CNCF and this has resulted into the CNCF Sandbox proposal after a month of discussion: https://github.com/cncf/toc/pull/92

When we initially created the Inception project level, it was intended to provide an avenue for technically interesting early-stage projects that were beneficial to the cloud-native community. We are transitioning Inception projects to the Sandbox. When we say that Sandbox projects are "early stage" this covers the following examples:

- New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. In the case of Kubernetes, the Sandbox is intended as a home for projects that would previously have started in the Kubernetes Incubator.

- Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need)

- Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects

- Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that

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

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support! Note, if the proposal passes, CNCF staff will make updates to website and all other marketing collateral regarding this change.

--

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

There’s been a desire within the CNCF TOC and community to provide further clarity around project maturity levels in CNCF and this has resulted into the CNCF Sandbox proposal after a month of discussion: https://github.com/cncf/toc/pull/92

When we initially created the Inception project level, it was intended to provide an avenue for technically interesting early-stage projects that were beneficial to the cloud-native community. We are transitioning Inception projects to the Sandbox. When we say that Sandbox projects are "early stage" this covers the following examples:

- New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. In the case of Kubernetes, the Sandbox is intended as a home for projects that would previously have started in the Kubernetes Incubator.

- Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need)

- Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects

- Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that

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

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support! Note, if the proposal passes, CNCF staff will make updates to website and all other marketing collateral regarding this change.

--

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

+1 non-binding

On Wed, Feb 28, 2018 at 1:13 PM, Richard Hartmann <richih@...> wrote:

On Wed, Feb 28, 2018 at 7:46 PM, Ruben Orduz <ruben@...> wrote:
> +1 non-biding on the spirit, -1 non-binding on the naming.

Same.