Describe the feature you'd like to have.
Gluster storage can currently be deployed either with gluster running in pods (converged) or using an external gluster cluster that lives outside the kubernetes cluster. The operator should have a operatorMode.mode: external for the "non-converged" (i.e., external) gluster deployment.
The functionality of such a mode of operation is limited to just managing the CSI driver.
What is the value to the end user? (why is it a priority?)
By supporting this "external" mode, user can continue to use separate Gluster deployments in their environment instead of forcing everyone using gluster to deploy it in a converged manner.
How will we know we have a good solution? (acceptance criteria)
The operator will deploy the CSI driver
Users will be able to dynamically provision & delete volumes by creating/deleting PVCs
Users will be able to access the dynamically provisioned volumes by referencing the PVCs in pods
The operator will maintain a Service that points to the external Gluster cluster
If the IP/DNS of a Gluster node is changed/added/removed in the cluster RC, the operator will update the Service as appropriate.
Describe the feature you'd like to have. Gluster storage can currently be deployed either with gluster running in pods (converged) or using an external gluster cluster that lives outside the kubernetes cluster. The operator should have a
operatorMode.mode: externalfor the "non-converged" (i.e., external) gluster deployment. The functionality of such a mode of operation is limited to just managing the CSI driver.What is the value to the end user? (why is it a priority?) By supporting this "external" mode, user can continue to use separate Gluster deployments in their environment instead of forcing everyone using gluster to deploy it in a converged manner.
How will we know we have a good solution? (acceptance criteria)
Additional context