> So no, I am not convinced yet. Not against it, but personally I would say it's not the only way forward. 100% agree to your whole answer -- Martin Verges Managing director Mobile: +49 174 9335695 E-Mail: martin.verges@xxxxxxxx Chat: https://t.me/MartinVerges croit GmbH, Freseniusstr. 31h, 81247 Munich CEO: Martin Verges - VAT-ID: DE310638492 Com. register: Amtsgericht Munich HRB 231263 Web: https://croit.io YouTube: https://goo.gl/PGE1Bx On Thu, 18 Mar 2021 at 09:42, Wido den Hollander <wido@xxxxxxxx> wrote: > > > On 18/03/2021 09:09, Janne Johansson wrote: > > Den ons 17 mars 2021 kl 20:17 skrev Matthew H <matthew.heler@xxxxxxxxxxx > >: > >> > >> "A containerized environment just makes troubleshooting more difficult, > getting access and retrieving details on Ceph processes isn't as > straightforward as with a non containerized infrastructure. I am still not > convinced that containerizing everything brings any benefits except the > collocation of services." > >> > >> It changes the way you troubleshoot, but I don't find it more difficult > in the issues I have seen and had. Even today without containers, all > services can be co-located within the same hosts (mons,mgrs,osds,mds).. Is > there a situation you've seen where that has not been the case? > > > > New ceph users pop in all the time on the #ceph IRC and have > > absolutely no idea on how to see the relevant logs from the > > containerized services. > > > > Me being one of the people that do run services on bare metal (and > > VMs) I actually can't help them, and it seems several other old ceph > > admins can't either. > > > > Me being one of them. > > Yes, it's all possible with containers, but it's different. And I don't > see the true benefit of running Ceph in Docker just yet. > > Another layer of abstraction which you need to understand. Also, when > you need to do real emergency stuff like working with > ceph-objectstore-tool to fix broken OSDs/PGs it's just much easier to > work on a bare-metal box than with containers (if you ask me). > > So no, I am not convinced yet. Not against it, but personally I would > say it's not the only way forward. > > DEB and RPM packages are still alive and kicking. > > Wido > > > Not that it is impossible or might not even be hard to get them, but > > somewhere in the "it is so easy to get it up and running, just pop a > > container and off you go" docs there seem to be a lack of the parts > > "when the OSD crashes at boot, run this to export the file normally > > called /var/log/ceph/ceph-osd.12.log" meaning it becomes a black box > > to the users and they are left to wipe/reinstall or something else > > when it doesn't work. At the end, I guess the project will see less > > useful reports with Assert Failed logs from impossible conditions and > > more people turning away from something that could be fixed in the > > long run. > > > > I get some of the advantages, and for stateless services elsewhere it > > might be gold to have containers, I am not equally enthusiastic about > > it for ceph. > > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |