You can unintentionally do a lot of things and this very simple reason is anything but a good argument.
Even containers have some base system underneath and to have yet another layer of complexity (usually almost identical to the host system) to work on is again, ... anything but attractive. Usually it is better to have a working packages for one or few most used distributions and people will create containers or whatever they need for themselves (if they will need it). Upgrades done with "package manager of the system" or "docker way", ... both need attention. Rok On Fri, Nov 21, 2025 at 3:28 PM Patrick Donnelly <[email protected]> wrote: > On Thu, Nov 20, 2025 at 1:20 AM Adrian Sevcenco <[email protected]> > wrote: > > > > Hi! Is there any possibility to use cephadm without the container based > tooling? > > (so to use bare-metal, with the packages directly installed on the > machine) > > Package based Ceph deployments, while popular, are not a good choice > in general. The very simple reason is that it makes upgrades more > dangerous: you can unintentionally upgrade services in the wrong order > due to failovers. Furthermore, it's harder to ensure dependencies are > aligned with what we test upstream. > > I'd be interested to hear ways in which we could make containers more > attractive (developer tooling, lower overhead, etc.) rather than ways > to return to a fundamentally flawed package based orchestration > framework. > > -- > Patrick Donnelly, Ph.D. > He / Him / His > Red Hat Partner Engineer > IBM, Inc. > GPG: 19F28A586F808C2402351B93C3301A3E258DD79D > _______________________________________________ > 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]
