Integration in Ceph Mgr or cephadm

[nixpanic]

Describe the feature you'd like to have

Once the ceph-csi-operator project is stable, write a Ceph Mgr module so that existing Ceph cluster can easily be used to provide storage functionality in one or more Kubernetes clusters.

Who is the end user and what is the use case where this feature will be valuable?

Users that have an existing Ceph cluster and want to setup Ceph-CSI storage functionality on Kubernetes clusters.

How will we know we have a good solution? (acceptance criteria)

The Ceph Mgr module should offer sufficient options to enable at least CephFS and RBD storage for common workloads (NFS can follow later if there is a need). It is expected that ceph-csi-operator will be deployed by Ceph Mgr on the target Kubernetes cluster(s).

[nb-ohad]

@nixpanic I am trying to understand the use case.

• What would this manager do exactly?
• How much overlap will it have with our intent to make the ocs-client-operator talk directly to a Ceph deployment? and what will be the differentiation between the two?
• Is this proposed as part of this repo? Or another repo that uses this operator?

[nixpanic]

Ceph Mgr and cephadm are part of the main Ceph repository. These are tools that a Ceph administrator is already using. When these administrators want to integrate the Ceph cluster into a Kubernetes environment, they would use the tools they know to deploy ceph-csi-operator on the Kubernetes environment without needing to learn much about Kubernetes.

The module should probably be part of the main Ceph repository. A reference to the deployment mechanism from within existing Ceph clusters can be linked in the documentation of ceph-csi-operator.

Once the APIs of ceph-csi-operator are stable, it should be communicated to the Ceph Mgr / cephadm developers. I'll open a tracker for that once I get clarity which component is most appropriate.

[nb-ohad]

@nixpanic I must swear that the cephadm was not there when I looked at the ticket. If it were I would have been able to interpret the proposal properly.

Regarding Ceph MGR, It is just an oversight from my side, generic names are hard to track and reason about. Anyways, your answer fully addressed my questions

[travisn]

Isn't helm expected to be the deployment approach for the ceph csi operator? This proposal seems reminiscent of years ago, trying to control Rook CRs from a mgr module which never really worked and was finally removed.

[nixpanic]

We're trying to understand what the most natural way for Ceph admins is to deploy Ceph-CSI on a Kubernetes cluster. Because Ceph admins are familiar with the Ceph tools, and less familiar with container platforms, having Ceph tools to handle the deployment and (minimal) configuration of ceph-csi-operator might be the simplest.

[Madhu-1]

we need to understand the end user(s) here and also we need to check what it didn't work with Rook and remove to avoid the same problems in the future. Once we have the first release of the ceph-csi-operator we can come back to this one.

[nb-ohad]

When looking at this issue from the perspective of this repo, it seems like an external consideration.
The concern regarding the way other repos/projects consume and automate on-top and around the APIs provided by this orchestrator needs to be discussed on the project themselves and not here.

Can we please close this issue and move the discussion to a place where it makes sense?