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.

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.

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(a)gmail.com> wrote: 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 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. yeah, all makes sense. -- Regards Kefu Chai