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.
Indeed, as if this has been such a huge problem. I would rather focus on testing the
updates. Because every update almost certainly is being followed by regression/fix lately.
I am already not installing new releases, and waiting for cowboy cephers to have found all
the bugs.
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.
Again has it ever been a problem? Besides ceph highly relies on kernel versions, so your
container environment is creating a dependency there. Furthermore deploying a 350MB
(compressed) image for an osd container of 5+17MB? That is like sending an elephant to the
Olympics figure skating.
As far as I know the core ceph team is working at
Redhat, so you are
basically getting 1 distro/package for free.
Yes afaik we should get support for el7, that was always written here. Yet python 3 is
messing with this now, and I wonder if the latest release of ceph is even running on
el7.
I do not know what to believe anymore. I just want to have my packages and I want to keep
decent cli tools to work with them. As I have been used to do. I do not want to have a 2nd
OC platform just for a ceph cli tool, so rookies are having an easier learning curve.
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.
I have seen no arguments why to use containers other than to try and make it
"easier" for new ceph people. Containers are not being used as they should be. I
wonder even how local persistent volumes are being assigned here. Because that requires
then the involvement of (I hope) csi drivers, and if you see how 'buggy' the ceph
csi driver is being coded, I do not think at this time it will adhere to a stable
solution.