spdk / spdk-csi

CSI driver to bring SPDK to Kubernetes storage through NVMe-oF or iSCSI. Supports dynamic volume provisioning and enables Pods to use SPDK storage transparently.
Apache License 2.0
73 stars 37 forks source link

Storage Management Agent #13

Open glimchb opened 2 years ago

glimchb commented 2 years ago

Question, will spdk-csi adopt new Storage Management Agent https://review.spdk.io/gerrit/c/spdk/spdk/+/10273/23 ?

cyb70289 commented 2 years ago

This looks interesting. I think spdkcsi should migrate to sma when it's ready.

glimchb commented 2 years ago

found some patches on review https://review.spdk.io/gerrit/c/spdk/spdk-csi/+/10321

glimchb commented 2 years ago

@ksztyber why patches above are abandoned ?

ksztyber commented 2 years ago

Those patches were just meant as a proof-of-concept to illustrate that the API could be potentially consumed by a CSI driver, but they weren't supposed to be ever merged.

With SMA, we're currently mostly focusing on a use-case where it's orchestrating SPDK application that is running on an IPU (Infrastructure Processing Unit, SmartNIC). In this scenario, you're not connecting to the targets from the host, but from the IPU, which will then present the remote volumes as if they're attached to local PCIe devices. In the patch series you've linked I've used an extra SPDK process running on a node that was emulating an IPU by establishing connections to remote targets and exposing volumes through NVMe-oF TCP subsystem over localhost to be then consumed by the node driver (so obviously, this isn't something that would make sense to use in production).

Perhaps it would make sense to have a new mode for the spdk-csi node driver to consume local PCIe devices created using SMA. This could be used with an IPU or with things like virtio-blk or vfio-user (so the node driver would be running on a VM). And if we ever extend SMA APIs to cover target use-case, we could use it in the controller driver too, but I don't think there are any plans to do that right now.