I think 2 things need to be clarified here: > [...] > Again, clean orchestration, being able to upgrade each deamon without > influencing running ones, this is just not possible with the native > packages. If a daemon is running on an operating system, it does not reload shared libraries or binaries. So upgrading a system != every daemon at the same time gets new executable content loaded. If a daemon restarts that particular moment of OS upgrade, then yes, then it loads the new binary. But are you able to hit that spot of a few minutes? Unlikely. Especially if you tested your upgrade on a staging environment before. > Being able to run on a lot more platforms, as native packages are just > not maintainable for all platforms that could easily run a docker daemon. Not biting on this one. If we talk platforms, you are basically fine for a lot of projects if you deliver a set of .rpms and a set of .debs. Or if you work closely together with the distros, then often that distro can actually help you building (and maintaining) that package. As far as I know the core ceph team is working at Redhat, so you are basically getting 1 distro/package for free. And while we are at claiming "on a lot more platforms", you are at the same time EXCLUDING a lot of platforms by saying "Linux based container" (remember Ceph on FreeBSD? [0]). I am aware that centralisation is in fashion, but coming from an Open Source background, there is one big reason to build Open Source software: to be portable and inclusive. I've experienced the time where the "only platform" was MS-DOS/Windows and I can assure anyone in here that "setting on one platform" instead of "being portable" is a shot in your own foot. History repeats. Cheers, Nico [0] https://docs.ceph.com/en/latest/install/manual-freebsd-deployment/ -- Sustainable and modern Infrastructures by ungleich.ch _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |