> > 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. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |