Fair enough. For sure ceph-deploy has had an uncertain lifetime; back in 2014 I was told it was on its way out, then it seemed to have a resurgence in popularity and support. At times upstream Ceph has made changes that were at odds with people running existing clusters in production, so I’m sensitive to ideas like this. That said, often there’s a genuine need for progress, eg. ceph-disk. I never had that many problems with it myself, though I recognize that it was … complex and messy so the move to ceph-volume made sense. So for ceph-deploy, I wouldn’t object to not updating it to work with future releases, but please don’t remove it from git or package repositories, as some people will need to use it indefinitely.

On Sep 3, 2020, at 7:24 AM, kefu chai <tchaikov@gmail.com> wrote:

On Fri, Aug 28, 2020 at 1:06 AM Anthony D'Atri <anthony.datri@gmail.com> wrote:

...

Lots of installations have significant automation and processes built around ceph-deploy. And few resources to repeatedly perform deep retrofits to accomodate moving targets. Heck, I still struggle to understand why the mon time sync status was moved.

ceph-ansible has matured nicely, but it doesn’t meet everyone’s needs.

cephadm in Octopus doesn’t retroactively manage clusters running older releases, and from what I can see on ceph-users it’s not mature. Heck I’m likely to wait for Pacific to give it time to work out the kinks.

Those running production workloads don’t have the option of throwing everything away and starting from scratch.

Hi Anthony, thanks for your inputs. i wanted to evaluate the interests in our community for a new release of ceph-deploy. so i will try to cut a new release of ceph-deploy to address the python3 support. but in the long run, i think we will only maintain ceph-ansible, and cephadm would be the recommended way to deploy a Ceph cluster in the long run.

as we know, "every mail client sucks" =) but it'd be a pain to maintain 3 tools for deploying at the same time. even if one of them does not suck in some cases.

...

...

On Aug 26, 2020, at 10:16 PM, kefu chai <tchaikov@gmail.com> wrote:

sorry for cross-posting. i sent this mail to ceph-maintainers two months ago, but got no responses so far. but after reading the comments in https://github.com/ceph/ceph-deploy/pull/496, i think i should check with ceph-devel as well. so i am forwarding this mail to ceph-devel for more inputs.

---------- Forwarded message --------- From: kefu chai <tchaikov@gmail.com> Date: Thu, Jun 4, 2020 at 6:39 PM Subject: is ceph-deploy still used? To: <ceph-maintainers@ceph.io> Cc: Neha Ojha <nojha@redhat.com>, Josh Durgin <jdurgin@redhat.com>, Brad Hubbard <bhubbard@redhat.com>, James Page <james.page@ubuntu.com>

hi ceph maintainers,

when reviewing ceph-deploy PRs, i am wondering why are we still maintaining this tool. as IIUC, we are supposed to deploy ceph using the Ansible playbooks offered by ceph-ansble[0]. and in future, we are more likely to deploy a ceph cluster using cephadm[1].

so the question is, are you still packaging / using ceph-deploy?

cheers,

-- [0] https://github.com/ceph/ceph-ansible [1] https://ceph.io/ceph-management/introducing-cephadm/

-- Regards Kefu Chai

-- Regards Kefu Chai _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

-- Regards Kefu Chai _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

Please don't remove and don't abandon it. There must be an option for simplified deployment without any orchestration, ceph-deploy is that option. I understand that you want to force everyone use containers, but it's definitely unnecessary to fast track it. There are funny things with it, too. For example, official Ceph containers have old smartctl thus drive health collection doesn't work. Another example is that it's currently impossible to change grafana url with cephadm because the orchestration module always resets it to a hardcoded value. And I'm sure there are plenty more issues...

...

That said, often there’s a genuine need for progress, eg. ceph-disk. I never had that many problems with it myself, though I recognize that it was … complex and messy so the move to ceph-volume made sense.

And there, there was a clear transition by removing ceph-disk from the code base and documenting the rationale for doing so.

...

So for ceph-deploy, I wouldn’t object to not updating it to work with future releases, but please don’t remove it from git or package repositories, as some people will need to use it indefinitely.

The challenge I see here: as long as ceph-deploy is included in the code base and packages (and docs), people assume it's still maintained. As this does not seem to be the case, it should officially be deprecated and removed eventually. Otherwise, we're just setting false expectations and cause frustration.

Lenz

On Mon, Sep 14, 2020 at 8:42 AM Neal Gompa <ngompa13@gmail.com> wrote:

On Fri, Sep 4, 2020 at 8:49 AM <vitalif@yourcmc.ru> wrote:

...

Please don't remove and don't abandon it. There must be an option for simplified deployment without any orchestration, ceph-deploy is that option.

what do you mean by "remove" it? ceph-deploy is not packaged anymore, and we just removed the documentation referencing it in master. yeah, i have to agree with you that ceph-deploy is probably the most painless option in that use case. i don't think we will going to nuke the repo, if this is your concern.

...

I understand that you want to force everyone use containers, but it's definitely unnecessary to fast track it.

There are funny things with it, too. For example, official Ceph containers have old smartctl thus drive health collection doesn't work. Another example is that it's currently impossible to change grafana url with cephadm because the orchestration module always resets it to a hardcoded value. And I'm sure there are plenty more issues...

i don't think i am in the position of forcing the community to do anything. i sent the mail just in hope to see if i should invest my time into looking into ceph-deploy pull requests and test failures, and try to cut a release. as it's not well maintained recently. also, please note, this is off-topic. but if you really care about the issues in ceph-deploy, cephadm or our official Ceph container, please feel free to improve these projects.

While I'm no advocate for ceph-deploy, I also don't particularly like cephadm and forcing containers for Ceph clusters. My personal deployments don't need it or gain anything from it, and the additional layer to manage just adds complexity with little value. Keep in mind that crazy container-based deployments are harder to manage, troubleshoot, and experiment with, which is discouraging to contributors and hobbyist users/developers.

yeah, all makes sense.

-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

-- Regards Kefu Chai