On Mon, Mar 23, 2015 at 9:58 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Mon, 23 Mar 2015, John Spray wrote: >> On 23/03/2015 10:04, Joao Eduardo Luis wrote: >> > I agree. And I don't think we need a new service for this, and I also don't >> > think we need to write stuff to the store. We can generate this information >> > when the monitor hits 'bootstrap()' and share it with the rest of the quorum >> > once an election finishes, and always keep it in memory (unless there's some >> > information that needs to be persisted, but I was under the impression that >> > was not the case). thanks João. yes, i will have another map in DataHealthService for the metadata. and update it in the way we update the health data. but will only send the MMonUpdateMetadata when the service bootstraps itself. and i will see if we can/need to remove the mon in the metadata map after it is removed from the quorum. >> >> Just to clarify, you mean we don't need to write the mon metadata to the >> store, but we'd still want to persist the MDS/OSD metadata - right? > > I think we definitely still want to persist those (as we already do > persist the OSD metadata). agreed, that's also my impression. > > Since we're reporting on running daemons we could get that without > persisting the mon metadata. I think the question is whether we want to > report on the last known running instance. I forget whether 'osd > metadata' includes OSDs that are down... if so, we may as well do > the same for mons too and persist that. yes, "osd metadata" also includes OSDs that are down, except for the ones explicitly removed using "osd rm". > > sage -- Regards Kefu Chai -- 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
