> > 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 <[email protected]>: > > 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 -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
