I bumped into this recently: https://samuel.karp.dev/blog/2021/05/running-freebsd-jails-with-containerd-1-5/ :) Kevin ________________________________________ From: Sage Weil <sage@xxxxxxxxxxxx> Sent: Thursday, June 24, 2021 2:06 PM To: Stefan Kooman Cc: Nico Schottelius; Kai Börnert; Marc; ceph-users Subject: Re: Why you might want packages not containers for Ceph deployments Check twice before you click! This email originated from outside PNNL. On Tue, Jun 22, 2021 at 1:25 PM Stefan Kooman <stefan@xxxxxx> wrote: > On 6/21/21 6:19 PM, Nico Schottelius wrote: > > 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]). > > Indeed, and that is a more fundamental question: how easy it is to make > Ceph a first-class citizen on non linux platforms. Was that ever a > (design) goal? But then again, if you would be able to port docker > natively to say OpenBSD, you should be able to run Ceph on it as well. Thank you for bringing this up. This is in fact a key reason why the orchestration abstraction works the way it does--to allow other runtime environments to be supported (FreeBSD! sysvinit/Devuan/whatever for systemd haters!) while ALSO allowing an integrated, user-friendly experience in which users workflow for adding/removing hosts, replacing failed OSDs, managing services (MDSs, RGWs, load balancers, etc) can be consistent across all platforms. For 10+ years we basically said "out of scope" to these pesky deployment details and left this job to Puppet, Chef, Ansible, ceph-deploy, rook, etc., but the result of that strategy was pretty clear: ceph was hard to use and the user experience dismal when compared to an integrated product from any half-decent enterprise storage company, or products like Martin's that capitalize on core ceph's bad UX. The question isn't whether we support other environments, but how. As I mentioned in one of my first messages, we can either (1) generalize cephadm to work in other environments (break the current systemd+container requirement), or (2) add another orchestrator backend that supports a new environment. I don't have any well-formed opinion here. There is a lot of pretty generic "orchestration" logic in cephadm right now that isn't related to systemd or containers that could either be pulled out of cephadm into the mgr/ochestrator layer or a library. Or an independent, fresh orch backend implementation could opt for a very different approach or set of opinions. Either way, my assumption has been that these other environments would probably not be docker|podman-based. In the case of FreeBSD we'd probably want to use jails or whatever. But anything is possible. s _______________________________________________ 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
 |