Allow enabling the topology feature for CSI

[piraeusdatastore]

Allow enabling the topology feature for CSI

[JoelColledge]

I don't know much about this feature, but here are my thoughts anyway.

Do we want to enable the topology feature?

Yes

If yes, do we want it configurable?

Yes

If yes, what should the default?

No. We do want to make it easy to try out the operator, but we don't want to lay traps for people who scale up with the default settings. To use this feature, the user must perform some additional steps to configure the topology information, so a user who is just trying out the operator probably won't benefit from it anyway. Also, there is some overlap between what this does and Stork and it might be confusing to have both running.

[JoelColledge]

This is actually a duplicate of #48, right?

[WanzenBug]

You are right.

[alexzhc]

CSI topology is especially needed when provisioning pure lvm volumes, which have no magic of drbd diskless for remote attachment.

[alexzhc]

People need native lvm/zvol volumes for performance applications like mysql cluster. Using stork for those pure lvm volumes is an overshoot. I would suggest leaving --feature-gates=Topology=true by default, and then only recognizing it with StorageClass parameter placementPolicy: FollowTopology

[WanzenBug]

One thing to also mention: The current implementation of this feature in linstor-csi, while better than the old one, is by no means perfect. A stumbling block that is probably very easy to run into: The accessible topologies of a node are only ever queried on plugin start. That means that any storage pool that is later added via LINSTOR API will not show up as accessible by the node. Only a restart of the node pod would trigger another check for new storage pools.

This is a limitation of the way kubernetes chose to implement the node info collection. I have not found a good workaround for this problem yet. This led me to disable this feature by default.