Review storage provisioning

[NicolasT]

Related to #1

We currently pre-provision a couple of LVM2 Logical Volumes of specific sizes and inject these as PersistentVolumes resources. This is a somewhat inflexible approach.

Though we likely should keep using LVM2 as a base storage technology, using e.g. CSI (as suggested by @Zempashi) could make this somewhat more flexible. CSI is, however, not yet entirely stable.

There's an LVM2 CSI driver from MesosSphere we may want to use or contribute to (https://github.com/mesosphere/csilvm, https://mesosphere.com/blog/open-source-storage-ecosystem/). There's another plugin at https://github.com/wavezhang/k8s-csi-lvm which seems less polished.

[Zempashi]

https://ember-csi.io/ one more in the list

[NicolasT]

Link dump:

kubernetes-retired/external-storage#651
kubernetes/community#1914
kubernetes-retired/external-storage#1015

[NicolasT]

@Zempashi I briefly looked into EmberCSI in the past, and had some concerns (maybe unwarranted, though):

• It requires a Cinder setup, which is quite a big deal
• If I'm not mistaken it creates Cinder volumes, then exposes them in K8s over iSCSI or whatever NAS/SAN protocol, so the storage is remote, not local...
• It requires a stateful data storage system setup somewhere. Ideally I think an LVM-based solution should only rely on what's available in the K8s API, and what's presented by the LVM subsystem on the local machine, instead of requiring some extra database to be deployed.

[Zempashi]

yes I had the same concern

[thomasdanan]

@slaperche-scality @gdemonet @NicolasT is this issue makes sense in the context of #1997 epic? or should we close it?

[gdemonet]

Implementation of the Storage Operator was already sufficient to close this issue IMO. Considerations w.r.t to using a CSI driver discussed here are not applicable to our Operator.

[thomasdanan]

CSI driver not applicable to Metal2 Storage Operator