This thread would not be so long if docker/containers solved the problems, but it did not. It solved some, but introduced new ones. So we cannot really say its better now. Again, I think focus should more on a working ceph with clean documentation while leaving software management, packages to admins. And staticilly linked binaries would certinly solve dependecy hell and "how to support other environments" for most of the cases. On Thu, 24 Jun 2021, 23:06 Sage Weil, <sage@xxxxxxxxxxxx> wrote: > 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
 |