> On the other hand, if we simply make an opinionated choice about some
> other per-host agent service, like we did in the original Calamari (which
> used salt and zeromq, IIRC), we'll probably end up offending more users
> than we please.
I think it fine for Ceph to have an opinionated story here, as long as it remains optional.
This would mean that we need to ensure a clean separation between “management” functions
(those that cater to administrators/users and are highly opinionated) and “data management”
functions (those that ensure the data is stored safely in the cluster and are not opinionated).
> Perhaps the way forward is to pick *some* external host agent and service
> to start with and ensure that it is integrated into ceph-mgr in a
> pluggable way such that we have (1) the osd:device mappings available, (2)
> a standard API for working with LEDs etc, and (3) a working plugin for
> twiddling the LEDs, but ensure that other "disk services" backends can
> also be used?
I believe there is a need for a ceph-mgr *agent* on every host, otherwise I don’t
see how one could implement some of the envisioned “management” functions for
ceph-mgr — this LED example is a good example. Turning the OSDs into this agent
seems to violate the clean separation I mention above. If there was a ceph-mgr-agent
I would recommend moving stat collection into it which currently has gone
into OSDs and MONs.
Bassam��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
