1. Messages
  2. first CSI example implementation

Re: first CSI example implementation

alexis richardson
 

Josh

How about people from docker and kubernetes?  Are they in the loop?

Alexis


On Sat, 1 Jul 2017, 06:48 Bernstein, Joshua, <Joshua.Bernstein@...> wrote:
Hi Alexis,

I'm not sure exactly the number of people, but it's been a large effort from everyone around the community between the folks at Mesosphere, those of us at Dell, and all of the rest of the folks in the community and companies that provided feedback and made the 0.1 spec come together so quickly. 

-Josh

On Jun 30, 2017, at 1:58 PM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

this looks like very quick progress; impressive

how many people are involved?


On Fri, Jun 30, 2017 at 7:08 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
FYI

---------- Forwarded message ----------
From: Clinton Kitson <clintonskitson@...>
Date: Sat, Jul 1, 2017 at 12:56 AM
Subject: first CSI example implementation
To: cncf-wg-storage <cncf-wg-storage@...>


Hello team,

Lots of great progress being made re the CSI specification.

On today's call Andrew Kutz of {code} by Dell EMC provided a first working example of the CSI specification written in Go. At this current time there is a single pull request that includes the different components that make all sides (server/client) of it work. This PR and future submitted code will mutate based on discussions, but for now it is a partially working example with AWS EBS!


There were specific goals in generating this:
- Generate a simple and pure CSI server side plugin endpoint in Go
- Pragmatically work through specification to identify gaps
- Create tools and tests that can assist with CI against the specification
- Discover if there are things that can be done to make it easier for plugin implementers
- Collect feedback about project desires as compared to examples and tools

He was able to show a few really cool things today.

1) a standalone AWS EBS plugin process (csp) that serves the CSI endpoints. This implementation has absolute minimal code and is intended to be a pure CSI implementation.

2) the client (csc) that is a tool that can be used to speak with the CSI endpoints. It provides functionality similar to what a CO would implement and thus makes it practical to truly test the specification and understand limitations.

3) the daemon (csd) that could possibly make it easier for plugin developers. We have identified input validation, logging, etc as common features that can possibly be shared across plugins. This was implemented by using Go plugins, where the csd is able to dynamically load the standalone csp's (same exact package as mentioned in #1). The csd actually exposes gRPC upward, and uses gRPC to speak in-memory via Go io.pipe package to any of the pure CSI plugin packages.

Both 1 & 3 are able to provide a mechanism to further test and actually have discussions around packaging and build process for the plugins since it is a real process now that serves as endpoints.

Looking forward to feedback on how the project might see these examples and tools fitting moving forward.


--
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/5c0bd689-fff0-4b81-8faf-edd389ce7d98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



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

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
Join {cncf-toc@lists.cncf.io to automatically receive all group messages.