ceph-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Kondratenko <denis.kondratenko@suse.com>
To: Travis Nielsen <tnielsen@redhat.com>,
	Sebastian Wagner <swagner@suse.com>,
	Patrick Donnelly <pdonnell@redhat.com>,
	Varsha Rao <varao@redhat.com>, Sebastien Han <seb@redhat.com>,
	Ceph Development List <ceph-devel@vger.kernel.org>
Subject: Re: Rook orchestrator module
Date: Wed, 7 Oct 2020 17:25:38 +0200	[thread overview]
Message-ID: <85e76f2e-660f-e4ba-2c5f-623ad98c4d2b@suse.com> (raw)
In-Reply-To: <CAByD1q-w83TQgCof5TJH0DWXPMobbqQQcbuaKsnE6PqNsaWqVw@mail.gmail.com>



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


  parent reply	other threads:[~2020-10-07 15:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 19:31 Rook orchestrator module Travis Nielsen
2020-09-29 19:50 ` Jason Dillaman
     [not found]   ` <CAByD1q89xGQGGj4=ySAw_hrHCq+t3zp9u8CkY-ey0_oo-7ntxA@mail.gmail.com>
     [not found]     ` <CA+aFP1Bxt9NgybrEKGRG2QDsxaoMqcHYyFOzLFeVZqc_AQW1_w@mail.gmail.com>
2020-09-29 21:05       ` Travis Nielsen
2020-10-07 15:25 ` Denis Kondratenko [this message]
2020-10-07 15:52 ` Patrick Donnelly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85e76f2e-660f-e4ba-2c5f-623ad98c4d2b@suse.com \
    --to=denis.kondratenko@suse.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=pdonnell@redhat.com \
    --cc=seb@redhat.com \
    --cc=swagner@suse.com \
    --cc=tnielsen@redhat.com \
    --cc=varao@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).