Containers are an excellent tool for developers and continuous testing in the development cycle but not a good solution for system tool deployment.
Could you please elaborate on the second part? Containers have succeeded not because they worked for developers, but because they solved issues throughout the entire software lifecycle, including deployment and maintenance.
An effort to provide native packages is therefore essential for enterprise ready deployment.
1. Ceph containers are built from distro packages, so containers and packages are not mutually exclusive. 2. That said, core distro packages are generally well tested and supported by major distro vendors such as Canonical or Red Hat. However, all distros also rely on repositories that are maintained by third parties with no guarantees (e.g. Ubuntu Universe, Fedora EPEL, ...). In some cases, these third parties are us, Ceph (and trust me, we're not such a large team). Whenever a bug or CVE is found, we have to drive ourselves all the distro package build process. Often these packages depend in turn on other packages not "maintained" by the Ceph team, which then involves some extra waits, and that slows down the whole process. Compared to that, a container native pipeline could release fixed images with almost zero latency and higher quality (because a vulnerable dependency might only compromise the container, not the whole system).
Regards --martin
Am 15.05.2025 10:22 schrieb Florent Carli <fcarli@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-leave@ceph.io