search

ceph / ceph-csi-operator

operator that deploys and manages the CephCSI plugins
Apache License 2.0
4 stars 6 forks source link

Add new controller for NodeFencing #3

Open Madhu-1 opened 1 month ago

Madhu-1 commented 1 month ago

This architecture is one-way only. CRD changes -> Configure drivers. I know that CSI drivers are usually pretty simple and can usually just be a deployment and daemonset, so maybe this really is the architecture. But the operator pattern follows control theory, where system states also result in the controller taking actions.

Are there any other :

are there ConfigMaps that cause reconciliations? does the controller respond to any other events like nodes going online/offline, or getting new labels applied? I feel like this is a bigger question: is this operator taking on the node loss fencing behavior? https://github.com/rook/rook/blob/682d639532534068a6154664119e10f0016f547d/design/ceph/node-loss-rbd-cephfs.md

I feel that, since the node fencing is both Kube-specific and involves CSI-Addons CRDs, it makes sense that the Ceph-CSI driver would be the right controller for this, so that non-Rook users could benefit from the fencing that RBD and CephFS need to function well in failure conditions.

_Originally posted by @BlaineEXE in https://github.com/ceph/ceph-csi-operator/pull/1#discussion_r1608500924

BlaineEXE commented 1 month ago

I feel like this should also be part of the design doc, even if the work isn't specifically completed in the first wave of operator development.

nb-ohad commented 1 month ago

The design doc is a living doc, there are a lot of other features that were discussed but pushed out for a future revision. We cannot, and should not, force ourselves to flesh out everything even before we have a minimal thing working.