toggle quoted message
Show quoted text
Forgive me, I am not quite sure I follow. What is your recommendation for rexray in the context of your description below?
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.
Technical Director @ NetApp
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@...
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@...
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.