On 9/29/20 9:31 PM, Travis Nielsen wrote: > The purpose of the orchestrator module was originally to provide a > common entry point either for Ceph CLI tools or the dashboard. This > would provide the constant interface to work with both Rook or cephadm > clusters. Patrick pointed out that the dashboard isn’t really a > scenario anymore for the orchestrator module. If so, the only > remaining usage is for CLI tools. And if we only have the CLI > scenario, this means that the CLI commands would be run from the > toolbox. But we are trying to avoid the toolbox. We should be putting > our effort into the CRDs, CSI driver, etc. I though it is exactly that, providing CLI to change something with the same unified (cephadm and Rook) orch interface. Like checking what resources are available, adding daemons, modifying DriveGroups, updating Ceph version and discovering that there are new updates in the registry. Sure node management probably is better on k8s level, and yes many of those tasks ppl could do modifying CRs and applying them. But it might be that Ceph admin would be inside toolbox to watch cluster state, fixing it and modifying things for a quite some time. So it (as idea) make sense for Ceph specific actions (services, drive configs, osd configs, troubleshoot, Ceph versions) to use Ceph CLI. And for k8s specific actions (labels, nodes, toleration, CRs creation and etc) to use k8s CLI. But that is more dev/eng point of view, don't know if that correlates to much with user experience. > > If the orchestrator module is creating CRs, we are likely doing > something wrong. We expect the cluster admin to create CRs. I would echo that. But changing CR for "cephVersion" looks like a good idea. BTW how update workflow of cephVersion is designed? There is no Helm chart (and that looks logical) and there is no other way to changed but edit the CR directly or by applying some manual changes in some self managed "yaml" file. In case of user, maybe I would like to control that mostly myself. But as vendor, vendor would like to control Ceph version, to limit user to supported images. > > Thus, I’d like to understand the scenarios where the rook orchestrator > module is needed. If there isn’t a need anymore since dashboard > requirements have changed, I’d propose the module can be removed. Maybe, but that also the question to the end user. cephadm is not widely adopted and there is not much feedback if extended orch is useful and it might be better unified with Rook. Also many devs are busy with cephadm so not much time to extend orch for Rook. > > Thanks, > Travis > Rook > Thanks, -- Denis Kondratenko Engineering Manager SUSE Linux Enterprise Storage SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
