my 2 cents, for the enterprise, there is nothing better then being able to have codified all the best practices around the proper orchestration of something as complicated as a ceph cluster into an orchestration layer and done so in a way that can help prevent mistakes. Without the orchestrator, each combination of distro/favorite config management tool must be independently coded up and that process often does not scale well. Inevitably there will be someone's favorite combination that is less well supported and feelings get hurt on one side or another. And, once that orchestration layer is there even more advanced functionality can be easily built on top. such as samba / nfs exports.
cephadm and rook-ceph very nicely solve multiple problems that are quite difficult to do without containers. Its unfortunate that creates a bit of a divide between container folks and non container folks but the container folks having a pretty solid standard/uniform base pays dividends. After literately decades of running ceph clusters, and being extremely careful with them, I have still had the orchestration layer save me from myself a few times. The layer has a lot more value then people give it credit for I think. Kevin ________________________________________ From: Martin Konold <martin.kon...@konsec.com> Sent: Thursday, May 15, 2025 11:55 AM To: Florent Carli; ceph-users@ceph.io Subject: [ceph-users] Re: [cephadm] Questions regarding cephadm infra-as-code philosophy, containerization, and trixie availability Check twice before you click! This email originated from outside PNNL. Hi, my 2 cents: Containers are an excellent tool for developers and continuous testing in the development cycle but not a good solution for system tool deployment. An effort to provide native packages is therefore essential for enterprise ready deployment. Regards --martin Am 15.05.2025 10:22 schrieb Florent Carli <fca...@gmail.com>: 2) Containerization vs. local dependencies Cephadm’s move to full containerization makes sense in principle, especially to avoid system-level dependencies. However, in practice, many operations (e.g., using ceph-bluestore-tool, or the python modules for Rados/rbd) still seem to require installing packages on th Is this the expected model : containers for core daemons, but local packages for tooling ? It feels somewhat contradictory, and I wonder if there's a clearer pattern or guidance for those cases. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
