The crush map changing causes a change in the osdmap version, I'm pretty sure.
On 06/08/2015 12:50 PM, Handzik, Joe wrote: > From what I see in the source file, we'd want to fix 'osd crush dump' somehow > too, right? I can take a look while I'm working in this area to see what I > can accomplish. > > Joe > > -----Original Message----- > From: John Spray [mailto:[email protected]] > Sent: Friday, June 05, 2015 7:39 PM > To: Handzik, Joe; Sage Weil > Cc: [email protected]; [email protected]; Dan Mick ([email protected]) > Subject: Re: Thoughts about metadata exposure in Calamari > > > > On 05/06/2015 20:33, Handzik, Joe wrote: >> I err in the direction of calling 'osd metadata' too, but it does mean that >> Calamari will need to add that call in (I'll leave it to Gregory to say if >> that is particularly undesirable). Do you think it would be worthwhile to >> better define the metadata bundle into a structure, or is it ok to leave it >> as a set of string pairs? > > Versioning of the metadata is something to consider. The "osd metadata" > stuff is outside the osdmap epochs, so anything that is consuming > updates to it is stuck with doing some kind of full polling as it > stands. It might be that some better interface with versions+deltas is > needed for a management layer to efficiently consume it. > > A version concept where the version is incremented when an OSD starts or > updates its metadata could make synchronization with a management layer > much more efficient. Efficiency matters here when we're calling on the > mons to serialize data for potentially 10000s of OSDs into JSON whenever > the management layer wants an update. > > John > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
