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.