Re: Why you might want packages not containers for Ceph deployments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> Again, this is meant as hopefully constructive feedback rather than
> complaints, but the feeling a get after having had fairly smooth
> operations with raw packages (including fixing previous bugs leading to
> severe crashes) and lately grinding our teeth a bit over cephadm is that
> it has helped automated a bunch of stuff that wasn't particularly
> difficult (it's nice to issue an update with a single command, but it
> works perfectly fine manually too) at the cost of making it WAY more
> difficult to fix things (not to mention simply get information about the
> cluster) when we have problems - and in the long run that's not a trade-
> off I'm entirely happy with :-)
> 

Everyone can only agree to keeping things simple. I honestly do not even know why you want to try cephadm. The containerized solution was developed to replace ceph deploy, ceph ansible etc. as a solution to make ceph installation for new users easier. That is exactly the reason (imho) why you should not use the containerized environment. Because a containerized environment has not as primaray task being an easy deployment tool. And because the focus is on easy deployment, the real characteristics of the containerized environment are being ignored during this development. Such as, you must be out of your mind to create a depency between ceph-osd/msd/mon/all and dockerd.

10 years(?) ago the people of mesos thought the docker containerizer was 'flacky' and created their own more stable containerizer. And still today, containers are being killed if dockerd is terminated. What some users had to learn the hard way, as recently posted here. 

Today's container solutions are not on the level where you can say, you require absolutely no knowledge to fix issues. So that means you would always require knowledge of the container solution + ceph to troubleshoot. And that is of course more knowledge, than just knowing ceph.

I would not be surprised if cephadm ends up like ceph deploy/ansible. 
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux