I understand that any project can choose to apply or not apply to be part of the CNCF Sandbox.

And while I realize the intent may not be to attempt to promote one project above another, per the CNCF Sandbox Guidelines the purpose of the CNCF Sandbox is to 1) "Encourage public visibility", 2) "Facilitate alignment with existing projects", 3) "Nurture projects", and 4) "Remove possible legal and governance obstacles to adoption and contribution".

As far as I can tell, the only major requirement for joining the sandbox, is support of "2 TOC sponsors" (which is also a little concerning to me).

So for projects that do apply to be part of the CNCF Sandbox, which projects will TOC members choose to sponsor? Specifically, will TOC members continue to sponsor any new block/file storage system that applies to be part of the CNCF? If so, why? What benefit does bringing in more block/file storage systems in to the CNCF bring to users of the CNCF ecosystem? If not, what criteria will we use to discern which ones we accept and which ones we don't accept?

On Wed, Apr 10, 2019 at 3:58 PM Fox, Kevin M <Kevin.Fox@...> wrote:

How does this relate to the established precedent of having multiple implementations of container runtimes be under the umbrella? (containerd, rkt, cri-o)

Kubernetes had a very tight dependency on the container runtime. Like the Rook decision, it made sense at the time.

As Kubernetes becomes more extensible we have to be be more thoughtful and intentional about the value of the projects we bring in to the CNCF ecosystem for our users.

On Wed, Apr 10, 2019 at 3:25 PM Quinton Hoole <quinton.hoole@...> wrote:

Hi Saad

Thanks for your questions.   Answers inline below.

---

From: cncf-toc@... [cncf-toc@...] on behalf of via Lists.Cncf.Io [saadali=google.com@...]
Sent: Wednesday, April 10, 2019 2:34 PM
To: cncf-wg-storage; cncf-toc@...; kubernetes-sig-storage
Cc: cncf-toc@...
Subject: [cncf-toc] Incubation of OpenEBS in to CNCF?

Hi CNCF Storage WG,

Based on recent presentation and discussions in the CNCF Storage WG meeting, I understand that we are considering adopting OpenEBS as a new CNCF sandbox or incubator project? Is that correct?

Quinton> Yes, sandbox.

If so, I'd like to understand the motivations for doing so? What will the benefit of doing so be for users of the CNCF ecosystem?

Quinton> Here is the motivation behind sandbox: https://github.com/cncf/toc/blob/master/process/sandbox.md  .  I think that answers most of your questions in more detail than I do here, but I'll add a few minor comments below.

As far as I understand, OpenEBS is a software defined storage system exposing block and file storage that is comprised of micro-services that run on top of Kubernetes.

There are many other projects that are doing similar things: including Portworx, Rook (already a CNCF incubator project), StorageOS, Robin Systems, and others. Kubernetes (with CSI) already allows workloads to consume any block or file storage system (including these ones) in a portable manner.

Quinton> Yes any open source project may decide to apply to donate their project to the CNCF.  If accepted by the TOC, they get a neutral home within which to collaborate, governance and other help from the CNCF, and the users of and contributors to the project get a level of assurance that the project will continue to operate as per the principles set out by the CNCF, its TOC, board etc.  Some projects choose to do that, and others do not.  Either way is fine. 

At the time when Rook was incubated in to the CNCF, Kubernetes wasn't the de facto container orchestration system, and so it made sense to promote projects that encouraged new types of workloads to run on top of Kubernetes.

That is no longer a concern, and given the diversity of projects in this space I don't see the benefit of promoting specific block and file storage implementations within the CNCF ecosystem.

Quinton> See above. Note that this is not an attempt to promote one project above another.  Any project may apply.  To my knowledge, none of the examples you gave have (yet) chosen to do so.

I want to stress that the team behind OpenEBS (at MayaData) is wonderful, and have been strong supports of the CNCF and Kubernetes. But at the same time I want to make sure we act intentionally within the CNCF for the clear benefit of users. And, at the very least, we should establish a clear strategy for adopting new projects in this space.

Quinton> I think that strategy is fairly clearly laid out above, and in other supporting CNCF docs. I'd be happy to hop on a call with you and anyone else who's interested to discuss further if there's a desire to do so.  Or we could just add it to the agenda for the next working group meeting in 2 weeks time.

Regards,

Saad Ali

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsubscribe@....
To post to this group, send email to kubernetes-sig-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/87D581F5165B024FB769D69D474DD224132CAC0C%40sjceml521-mbs.china.huawei.com.
For more options, visit https://groups.google.com/d/optout.

Based on this thread, I think I finally internalized that the CNCF Sandbox does not represent an endorsement by the CNCF of a project. It is a place to nurture new projects that may graduate to "endorsed" CNCF projects (i.e. incubating stage).

Therefore I withdraw my objections to the induction of OpenEBS as a CNCF Sandbox project. I do think we (the CNCF TOC and community) can do a better job of communicating that sandbox projects are not officially endorsed, and we should work on improving the process for having projects graduate to incubating stage.

Thank you all for taking the time to discuss this with me here and offline!

On Wed, Apr 10, 2019 at 4:09 PM Saad Ali <saadali@...> wrote:

I understand that any project can choose to apply or not apply to be part of the CNCF Sandbox.

And while I realize the intent may not be to attempt to promote one project above another, per the CNCF Sandbox Guidelines the purpose of the CNCF Sandbox is to 1) "Encourage public visibility", 2) "Facilitate alignment with existing projects", 3) "Nurture projects", and 4) "Remove possible legal and governance obstacles to adoption and contribution".

As far as I can tell, the only major requirement for joining the sandbox, is support of "2 TOC sponsors" (which is also a little concerning to me).

So for projects that do apply to be part of the CNCF Sandbox, which projects will TOC members choose to sponsor? Specifically, will TOC members continue to sponsor any new block/file storage system that applies to be part of the CNCF? If so, why? What benefit does bringing in more block/file storage systems in to the CNCF bring to users of the CNCF ecosystem? If not, what criteria will we use to discern which ones we accept and which ones we don't accept?

On Wed, Apr 10, 2019 at 3:58 PM Fox, Kevin M <Kevin.Fox@...> wrote:

How does this relate to the established precedent of having multiple implementations of container runtimes be under the umbrella? (containerd, rkt, cri-o)

Kubernetes had a very tight dependency on the container runtime. Like the Rook decision, it made sense at the time.

As Kubernetes becomes more extensible we have to be be more thoughtful and intentional about the value of the projects we bring in to the CNCF ecosystem for our users.

On Wed, Apr 10, 2019 at 3:25 PM Quinton Hoole <quinton.hoole@...> wrote:

Hi Saad

Thanks for your questions.   Answers inline below.

---

From: cncf-toc@... [cncf-toc@...] on behalf of via Lists.Cncf.Io [saadali=google.com@...]
Sent: Wednesday, April 10, 2019 2:34 PM
To: cncf-wg-storage; cncf-toc@...; kubernetes-sig-storage
Cc: cncf-toc@...
Subject: [cncf-toc] Incubation of OpenEBS in to CNCF?

Hi CNCF Storage WG,

Based on recent presentation and discussions in the CNCF Storage WG meeting, I understand that we are considering adopting OpenEBS as a new CNCF sandbox or incubator project? Is that correct?

Quinton> Yes, sandbox.

If so, I'd like to understand the motivations for doing so? What will the benefit of doing so be for users of the CNCF ecosystem?

Quinton> Here is the motivation behind sandbox: https://github.com/cncf/toc/blob/master/process/sandbox.md  .  I think that answers most of your questions in more detail than I do here, but I'll add a few minor comments below.

As far as I understand, OpenEBS is a software defined storage system exposing block and file storage that is comprised of micro-services that run on top of Kubernetes.

There are many other projects that are doing similar things: including Portworx, Rook (already a CNCF incubator project), StorageOS, Robin Systems, and others. Kubernetes (with CSI) already allows workloads to consume any block or file storage system (including these ones) in a portable manner.

Quinton> Yes any open source project may decide to apply to donate their project to the CNCF.  If accepted by the TOC, they get a neutral home within which to collaborate, governance and other help from the CNCF, and the users of and contributors to the project get a level of assurance that the project will continue to operate as per the principles set out by the CNCF, its TOC, board etc.  Some projects choose to do that, and others do not.  Either way is fine. 

At the time when Rook was incubated in to the CNCF, Kubernetes wasn't the de facto container orchestration system, and so it made sense to promote projects that encouraged new types of workloads to run on top of Kubernetes.

That is no longer a concern, and given the diversity of projects in this space I don't see the benefit of promoting specific block and file storage implementations within the CNCF ecosystem.

Quinton> See above. Note that this is not an attempt to promote one project above another.  Any project may apply.  To my knowledge, none of the examples you gave have (yet) chosen to do so.

I want to stress that the team behind OpenEBS (at MayaData) is wonderful, and have been strong supports of the CNCF and Kubernetes. But at the same time I want to make sure we act intentionally within the CNCF for the clear benefit of users. And, at the very least, we should establish a clear strategy for adopting new projects in this space.

Quinton> I think that strategy is fairly clearly laid out above, and in other supporting CNCF docs. I'd be happy to hop on a call with you and anyone else who's interested to discuss further if there's a desire to do so.  Or we could just add it to the agenda for the next working group meeting in 2 weeks time.

Regards,

Saad Ali

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsubscribe@....
To post to this group, send email to kubernetes-sig-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/87D581F5165B024FB769D69D474DD224132CAC0C%40sjceml521-mbs.china.huawei.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cncf-wg-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cncf-wg-storage+unsubscribe@....
To post to this group, send email to cncf-wg-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/cncf-wg-storage/CABBBJP0eCYerqfV3NG3WVtPtsH_rP0tCXBgoqKCwJxXo-NckTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Saad

I agree, and have worked long and hard on and with the TOC to have any explicit or implicit endorsement of Sandbox projects removed. Whatever remains is despite my best efforts.  If you spot any, please bring them to the attention of the TOC, who have unequivocally decided on the matter.  What remains is execution.

Q

On Fri, Apr 12, 2019 at 11:29 AM 'Saad Ali' via cncf-wg-storage <cncf-wg-storage@...> wrote:

Based on this thread, I think I finally internalized that the CNCF Sandbox does not represent an endorsement by the CNCF of a project. It is a place to nurture new projects that may graduate to "endorsed" CNCF projects (i.e. incubating stage).

Therefore I withdraw my objections to the induction of OpenEBS as a CNCF Sandbox project. I do think we (the CNCF TOC and community) can do a better job of communicating that sandbox projects are not officially endorsed, and we should work on improving the process for having projects graduate to incubating stage.

Thank you all for taking the time to discuss this with me here and offline!

On Wed, Apr 10, 2019 at 4:09 PM Saad Ali <saadali@...> wrote:

I understand that any project can choose to apply or not apply to be part of the CNCF Sandbox.

And while I realize the intent may not be to attempt to promote one project above another, per the CNCF Sandbox Guidelines the purpose of the CNCF Sandbox is to 1) "Encourage public visibility", 2) "Facilitate alignment with existing projects", 3) "Nurture projects", and 4) "Remove possible legal and governance obstacles to adoption and contribution".

As far as I can tell, the only major requirement for joining the sandbox, is support of "2 TOC sponsors" (which is also a little concerning to me).

So for projects that do apply to be part of the CNCF Sandbox, which projects will TOC members choose to sponsor? Specifically, will TOC members continue to sponsor any new block/file storage system that applies to be part of the CNCF? If so, why? What benefit does bringing in more block/file storage systems in to the CNCF bring to users of the CNCF ecosystem? If not, what criteria will we use to discern which ones we accept and which ones we don't accept?

On Wed, Apr 10, 2019 at 3:58 PM Fox, Kevin M <Kevin.Fox@...> wrote:

How does this relate to the established precedent of having multiple implementations of container runtimes be under the umbrella? (containerd, rkt, cri-o)

Kubernetes had a very tight dependency on the container runtime. Like the Rook decision, it made sense at the time.

As Kubernetes becomes more extensible we have to be be more thoughtful and intentional about the value of the projects we bring in to the CNCF ecosystem for our users.

On Wed, Apr 10, 2019 at 3:25 PM Quinton Hoole <quinton.hoole@...> wrote:

Hi Saad

Thanks for your questions.   Answers inline below.

---

From: cncf-toc@... [cncf-toc@...] on behalf of via Lists.Cncf.Io [saadali=google.com@...]
Sent: Wednesday, April 10, 2019 2:34 PM
To: cncf-wg-storage; cncf-toc@...; kubernetes-sig-storage
Cc: cncf-toc@...
Subject: [cncf-toc] Incubation of OpenEBS in to CNCF?

Hi CNCF Storage WG,

Based on recent presentation and discussions in the CNCF Storage WG meeting, I understand that we are considering adopting OpenEBS as a new CNCF sandbox or incubator project? Is that correct?

Quinton> Yes, sandbox.

If so, I'd like to understand the motivations for doing so? What will the benefit of doing so be for users of the CNCF ecosystem?

Quinton> Here is the motivation behind sandbox: https://github.com/cncf/toc/blob/master/process/sandbox.md  .  I think that answers most of your questions in more detail than I do here, but I'll add a few minor comments below.

As far as I understand, OpenEBS is a software defined storage system exposing block and file storage that is comprised of micro-services that run on top of Kubernetes.

There are many other projects that are doing similar things: including Portworx, Rook (already a CNCF incubator project), StorageOS, Robin Systems, and others. Kubernetes (with CSI) already allows workloads to consume any block or file storage system (including these ones) in a portable manner.

Quinton> Yes any open source project may decide to apply to donate their project to the CNCF.  If accepted by the TOC, they get a neutral home within which to collaborate, governance and other help from the CNCF, and the users of and contributors to the project get a level of assurance that the project will continue to operate as per the principles set out by the CNCF, its TOC, board etc.  Some projects choose to do that, and others do not.  Either way is fine. 

At the time when Rook was incubated in to the CNCF, Kubernetes wasn't the de facto container orchestration system, and so it made sense to promote projects that encouraged new types of workloads to run on top of Kubernetes.

That is no longer a concern, and given the diversity of projects in this space I don't see the benefit of promoting specific block and file storage implementations within the CNCF ecosystem.

Quinton> See above. Note that this is not an attempt to promote one project above another.  Any project may apply.  To my knowledge, none of the examples you gave have (yet) chosen to do so.

I want to stress that the team behind OpenEBS (at MayaData) is wonderful, and have been strong supports of the CNCF and Kubernetes. But at the same time I want to make sure we act intentionally within the CNCF for the clear benefit of users. And, at the very least, we should establish a clear strategy for adopting new projects in this space.

Quinton> I think that strategy is fairly clearly laid out above, and in other supporting CNCF docs. I'd be happy to hop on a call with you and anyone else who's interested to discuss further if there's a desire to do so.  Or we could just add it to the agenda for the next working group meeting in 2 weeks time.

Regards,

Saad Ali

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsubscribe@....
To post to this group, send email to kubernetes-sig-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/87D581F5165B024FB769D69D474DD224132CAC0C%40sjceml521-mbs.china.huawei.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cncf-wg-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cncf-wg-storage+unsubscribe@....
To post to this group, send email to cncf-wg-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/cncf-wg-storage/CABBBJP0eCYerqfV3NG3WVtPtsH_rP0tCXBgoqKCwJxXo-NckTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
quinton@...

This does bring up a point where perhaps we (TOC + TOC contributors) need to create a means of communicating this more simplistically to any new user/developer/contributor so they can understand the sandbox differentiation. I, like Quinton, was part of the group that facilitated creating this level and being very intentional about what it means, but not sure those new to CNCF will see it right out of the gate.

Open to suggestions from you, Saad, since you are bringing this to light again for us.

I am happy to help drive/participate in those discussions.

Erin

On Fri, Apr 12, 2019 at 12:50 PM Quinton Hoole <quinton@...> wrote:

Thanks Saad

I agree, and have worked long and hard on and with the TOC to have any explicit or implicit endorsement of Sandbox projects removed. Whatever remains is despite my best efforts.  If you spot any, please bring them to the attention of the TOC, who have unequivocally decided on the matter.  What remains is execution.

Q

On Fri, Apr 12, 2019 at 11:29 AM 'Saad Ali' via cncf-wg-storage <cncf-wg-storage@...> wrote:

Based on this thread, I think I finally internalized that the CNCF Sandbox does not represent an endorsement by the CNCF of a project. It is a place to nurture new projects that may graduate to "endorsed" CNCF projects (i.e. incubating stage).

Therefore I withdraw my objections to the induction of OpenEBS as a CNCF Sandbox project. I do think we (the CNCF TOC and community) can do a better job of communicating that sandbox projects are not officially endorsed, and we should work on improving the process for having projects graduate to incubating stage.

Thank you all for taking the time to discuss this with me here and offline!

On Wed, Apr 10, 2019 at 4:09 PM Saad Ali <saadali@...> wrote:

I understand that any project can choose to apply or not apply to be part of the CNCF Sandbox.

And while I realize the intent may not be to attempt to promote one project above another, per the CNCF Sandbox Guidelines the purpose of the CNCF Sandbox is to 1) "Encourage public visibility", 2) "Facilitate alignment with existing projects", 3) "Nurture projects", and 4) "Remove possible legal and governance obstacles to adoption and contribution".

As far as I can tell, the only major requirement for joining the sandbox, is support of "2 TOC sponsors" (which is also a little concerning to me).

So for projects that do apply to be part of the CNCF Sandbox, which projects will TOC members choose to sponsor? Specifically, will TOC members continue to sponsor any new block/file storage system that applies to be part of the CNCF? If so, why? What benefit does bringing in more block/file storage systems in to the CNCF bring to users of the CNCF ecosystem? If not, what criteria will we use to discern which ones we accept and which ones we don't accept?

On Wed, Apr 10, 2019 at 3:58 PM Fox, Kevin M <Kevin.Fox@...> wrote:

How does this relate to the established precedent of having multiple implementations of container runtimes be under the umbrella? (containerd, rkt, cri-o)

Kubernetes had a very tight dependency on the container runtime. Like the Rook decision, it made sense at the time.

As Kubernetes becomes more extensible we have to be be more thoughtful and intentional about the value of the projects we bring in to the CNCF ecosystem for our users.

On Wed, Apr 10, 2019 at 3:25 PM Quinton Hoole <quinton.hoole@...> wrote:

Hi Saad

Thanks for your questions.   Answers inline below.

---

From: cncf-toc@... [cncf-toc@...] on behalf of via Lists.Cncf.Io [saadali=google.com@...]
Sent: Wednesday, April 10, 2019 2:34 PM
To: cncf-wg-storage; cncf-toc@...; kubernetes-sig-storage
Cc: cncf-toc@...
Subject: [cncf-toc] Incubation of OpenEBS in to CNCF?

Hi CNCF Storage WG,

Based on recent presentation and discussions in the CNCF Storage WG meeting, I understand that we are considering adopting OpenEBS as a new CNCF sandbox or incubator project? Is that correct?

Quinton> Yes, sandbox.

If so, I'd like to understand the motivations for doing so? What will the benefit of doing so be for users of the CNCF ecosystem?

Quinton> Here is the motivation behind sandbox: https://github.com/cncf/toc/blob/master/process/sandbox.md  .  I think that answers most of your questions in more detail than I do here, but I'll add a few minor comments below.

As far as I understand, OpenEBS is a software defined storage system exposing block and file storage that is comprised of micro-services that run on top of Kubernetes.

There are many other projects that are doing similar things: including Portworx, Rook (already a CNCF incubator project), StorageOS, Robin Systems, and others. Kubernetes (with CSI) already allows workloads to consume any block or file storage system (including these ones) in a portable manner.

Quinton> Yes any open source project may decide to apply to donate their project to the CNCF.  If accepted by the TOC, they get a neutral home within which to collaborate, governance and other help from the CNCF, and the users of and contributors to the project get a level of assurance that the project will continue to operate as per the principles set out by the CNCF, its TOC, board etc.  Some projects choose to do that, and others do not.  Either way is fine. 

At the time when Rook was incubated in to the CNCF, Kubernetes wasn't the de facto container orchestration system, and so it made sense to promote projects that encouraged new types of workloads to run on top of Kubernetes.

That is no longer a concern, and given the diversity of projects in this space I don't see the benefit of promoting specific block and file storage implementations within the CNCF ecosystem.

Quinton> See above. Note that this is not an attempt to promote one project above another.  Any project may apply.  To my knowledge, none of the examples you gave have (yet) chosen to do so.

I want to stress that the team behind OpenEBS (at MayaData) is wonderful, and have been strong supports of the CNCF and Kubernetes. But at the same time I want to make sure we act intentionally within the CNCF for the clear benefit of users. And, at the very least, we should establish a clear strategy for adopting new projects in this space.

Quinton> I think that strategy is fairly clearly laid out above, and in other supporting CNCF docs. I'd be happy to hop on a call with you and anyone else who's interested to discuss further if there's a desire to do so.  Or we could just add it to the agenda for the next working group meeting in 2 weeks time.

Regards,

Saad Ali

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsubscribe@....
To post to this group, send email to kubernetes-sig-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/87D581F5165B024FB769D69D474DD224132CAC0C%40sjceml521-mbs.china.huawei.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cncf-wg-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cncf-wg-storage+unsubscribe@....
To post to this group, send email to cncf-wg-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/cncf-wg-storage/CABBBJP0eCYerqfV3NG3WVtPtsH_rP0tCXBgoqKCwJxXo-NckTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
quinton@...

+1, well said Erin

On Fri, 12 Apr 2019, 20:03 Erin Boyd, <eboyd@...> wrote:

This does bring up a point where perhaps we (TOC + TOC contributors) need to create a means of communicating this more simplistically to any new user/developer/contributor so they can understand the sandbox differentiation. I, like Quinton, was part of the group that facilitated creating this level and being very intentional about what it means, but not sure those new to CNCF will see it right out of the gate.

Open to suggestions from you, Saad, since you are bringing this to light again for us.

I am happy to help drive/participate in those discussions.

Erin

On Fri, Apr 12, 2019 at 12:50 PM Quinton Hoole <quinton@...> wrote:

Thanks Saad

I agree, and have worked long and hard on and with the TOC to have any explicit or implicit endorsement of Sandbox projects removed. Whatever remains is despite my best efforts.  If you spot any, please bring them to the attention of the TOC, who have unequivocally decided on the matter.  What remains is execution.

Q

On Fri, Apr 12, 2019 at 11:29 AM 'Saad Ali' via cncf-wg-storage <cncf-wg-storage@...> wrote:

Based on this thread, I think I finally internalized that the CNCF Sandbox does not represent an endorsement by the CNCF of a project. It is a place to nurture new projects that may graduate to "endorsed" CNCF projects (i.e. incubating stage).

Therefore I withdraw my objections to the induction of OpenEBS as a CNCF Sandbox project. I do think we (the CNCF TOC and community) can do a better job of communicating that sandbox projects are not officially endorsed, and we should work on improving the process for having projects graduate to incubating stage.

Thank you all for taking the time to discuss this with me here and offline!

On Wed, Apr 10, 2019 at 4:09 PM Saad Ali <saadali@...> wrote:

I understand that any project can choose to apply or not apply to be part of the CNCF Sandbox.

And while I realize the intent may not be to attempt to promote one project above another, per the CNCF Sandbox Guidelines the purpose of the CNCF Sandbox is to 1) "Encourage public visibility", 2) "Facilitate alignment with existing projects", 3) "Nurture projects", and 4) "Remove possible legal and governance obstacles to adoption and contribution".

As far as I can tell, the only major requirement for joining the sandbox, is support of "2 TOC sponsors" (which is also a little concerning to me).

So for projects that do apply to be part of the CNCF Sandbox, which projects will TOC members choose to sponsor? Specifically, will TOC members continue to sponsor any new block/file storage system that applies to be part of the CNCF? If so, why? What benefit does bringing in more block/file storage systems in to the CNCF bring to users of the CNCF ecosystem? If not, what criteria will we use to discern which ones we accept and which ones we don't accept?

On Wed, Apr 10, 2019 at 3:58 PM Fox, Kevin M <Kevin.Fox@...> wrote:

How does this relate to the established precedent of having multiple implementations of container runtimes be under the umbrella? (containerd, rkt, cri-o)

Kubernetes had a very tight dependency on the container runtime. Like the Rook decision, it made sense at the time.

As Kubernetes becomes more extensible we have to be be more thoughtful and intentional about the value of the projects we bring in to the CNCF ecosystem for our users.

On Wed, Apr 10, 2019 at 3:25 PM Quinton Hoole <quinton.hoole@...> wrote:

Hi Saad

Thanks for your questions.   Answers inline below.

---

From: cncf-toc@... [cncf-toc@...] on behalf of via Lists.Cncf.Io [saadali=google.com@...]
Sent: Wednesday, April 10, 2019 2:34 PM
To: cncf-wg-storage; cncf-toc@...; kubernetes-sig-storage
Cc: cncf-toc@...
Subject: [cncf-toc] Incubation of OpenEBS in to CNCF?

Hi CNCF Storage WG,

Based on recent presentation and discussions in the CNCF Storage WG meeting, I understand that we are considering adopting OpenEBS as a new CNCF sandbox or incubator project? Is that correct?

Quinton> Yes, sandbox.

If so, I'd like to understand the motivations for doing so? What will the benefit of doing so be for users of the CNCF ecosystem?

Quinton> Here is the motivation behind sandbox: https://github.com/cncf/toc/blob/master/process/sandbox.md  .  I think that answers most of your questions in more detail than I do here, but I'll add a few minor comments below.

As far as I understand, OpenEBS is a software defined storage system exposing block and file storage that is comprised of micro-services that run on top of Kubernetes.

There are many other projects that are doing similar things: including Portworx, Rook (already a CNCF incubator project), StorageOS, Robin Systems, and others. Kubernetes (with CSI) already allows workloads to consume any block or file storage system (including these ones) in a portable manner.

Quinton> Yes any open source project may decide to apply to donate their project to the CNCF.  If accepted by the TOC, they get a neutral home within which to collaborate, governance and other help from the CNCF, and the users of and contributors to the project get a level of assurance that the project will continue to operate as per the principles set out by the CNCF, its TOC, board etc.  Some projects choose to do that, and others do not.  Either way is fine. 

At the time when Rook was incubated in to the CNCF, Kubernetes wasn't the de facto container orchestration system, and so it made sense to promote projects that encouraged new types of workloads to run on top of Kubernetes.

That is no longer a concern, and given the diversity of projects in this space I don't see the benefit of promoting specific block and file storage implementations within the CNCF ecosystem.

Quinton> See above. Note that this is not an attempt to promote one project above another.  Any project may apply.  To my knowledge, none of the examples you gave have (yet) chosen to do so.

I want to stress that the team behind OpenEBS (at MayaData) is wonderful, and have been strong supports of the CNCF and Kubernetes. But at the same time I want to make sure we act intentionally within the CNCF for the clear benefit of users. And, at the very least, we should establish a clear strategy for adopting new projects in this space.

Quinton> I think that strategy is fairly clearly laid out above, and in other supporting CNCF docs. I'd be happy to hop on a call with you and anyone else who's interested to discuss further if there's a desire to do so.  Or we could just add it to the agenda for the next working group meeting in 2 weeks time.

Regards,

Saad Ali

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsubscribe@....
To post to this group, send email to kubernetes-sig-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/87D581F5165B024FB769D69D474DD224132CAC0C%40sjceml521-mbs.china.huawei.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cncf-wg-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cncf-wg-storage+unsubscribe@....
To post to this group, send email to cncf-wg-storage@....
To view this discussion on the web visit https://groups.google.com/d/msgid/cncf-wg-storage/CABBBJP0eCYerqfV3NG3WVtPtsH_rP0tCXBgoqKCwJxXo-NckTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
quinton@...