On Tue, Jun 22, 2021 at 1:25 PM Stefan Kooman <stefan(a)bit.nl> 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