Hi, Whether containers are good or not is a separate discussion where I suspect there won't be consensus in the near future.
However, after just having looked at the documentation again, my main point would be that when a major stable open source project recommends a specific installation method (=cephadm) first in the "getting started" guide, users are going to expect that's the alternative things are documented for, which isn't quite the case for cephadm (yet). Most users will probably accept either solution as long as there is ONE clear & well-documented way of working with ceph - but the current setup of even having the simple (?) getting started guide talk about at least three different ways without clearly separating their documentation seems like a guarantee for long-term confusion and higher entry barriers for new users, which I assume is the opposite of the goal of cephadm! Cheers, Erik Erik Lindahl <erik.lind...@scilifelab.se> Professor of Biophysics Science for Life Laboratory Stockholm University & KTH Office (SciLifeLab): +46 8 524 81567 Cell (Sweden): +46 73 4618050 Cell (US): +1 (650) 924 7674 > On 17 Aug 2021, at 16:29, Marc <m...@f1-outsourcing.eu> wrote: > > >> >> >> 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@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
