On Mon, Jun 19, 2017 at 12:26 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > I wrote up a quick proposal at > > http://pad.ceph.com/p/service-map > > Basic idea: > > - generic ServiceMap of service -> daemon -> metadata and status > - managed/persisted by mon > - librados interface to register as service X name Y (e.g., 'rgw.foo') > - librados will send regular beacon to mon to keep entry alive > - various mon commands to dump all or part of the service map I am deeply uncomfortable with putting this stuff into the monitor (at least, directly). The main purpose we've discussed is to enable manager dashboard display of these services, along with stats collection, and there's no reason for that to go anywhere other than the manager — in fact, routing it through the monitor is inimical to timely updates of statistics. Why do you want to do that instead of letting it be handled by the manager, which can aggregate and persist whatever data it likes in a convenient form — and in ways which are mindful of monitor IO abilities? (The librados interface looks fine to me, though.) -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
