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@xxxxxxxxx> wrote: > > On Fri, Aug 28, 2020 at 1:06 AM Anthony D'Atri <anthony.datri@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> >>> Date: Thu, Jun 4, 2020 at 6:39 PM >>> Subject: is ceph-deploy still used? >>> To: <ceph-maintainers@xxxxxxx> >>> Cc: Neha Ojha <nojha@xxxxxxxxxx>, Josh Durgin <jdurgin@xxxxxxxxxx>, >>> Brad Hubbard <bhubbard@xxxxxxxxxx>, James Page <james.page@xxxxxxxxxx> >>> >>> >>> 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@xxxxxxx >>> To unsubscribe send an email to dev-leave@xxxxxxx >> > > > -- > Regards > Kefu Chai > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
