On Fri, 5 Jun 2015, Handzik, Joe wrote: > Adding in ceph-devel, this time without html formatting... > > Rest-of-community, > > After talking to Gregory, we can see any of the solutions in the original > email being acceptable, but it depends on what others are using and how > changes would affect them. > > 1. Is anyone actively using the 'osd metadata' monitor command? > 2. Would anyone be upset if the data from 'osd metadata' came along for the > ride in 'osd dump'? (see: > https://github.com/ceph/ceph/blob/master/src/mon/OSDMonitor.cc#L3006 and > https://github.com/ceph/ceph/blob/master/src/mon/OSDMonitor.cc#L2910 ) > 3. Or, would a better solution be to push device, partition, and filesystem > information into the 'osd dump' dataset, and leave 'osd metadata' out of it? > (some of this stuff would move elsewhere: > https://github.com/ceph/ceph/blob/master/src/osd/OSD.cc#L4521 ) > a. Some of the data in the metadata bundle looked interesting, that's another > motivating factor behind carrying it with the device and partition data in my > current PR: https://github.com/ceph/ceph/pull/4699. Might be a better fit for > a different location though, seems overkill for every OSD to push this much > system data up. > 4. Or, is everything so fragile that we should just add an 'osd metadata' > call into Calamari (alongside the 'osd dump' call: > https://github.com/ceph/calamari/blob/0964ec9b82c1182e97f00b13dc157f328f75e294/salt/srv/salt/_modules/ceph.py#L367 > )
It is perhaps an implementation artifact, but: 'osd dump' is dumping (just) the contents of the OSDMap structure, and matches what you would get from ceph osd getmap -o foo osdmaptool --print foo (or --print-json) We definitely don't want the 'osd metadata' stuff to go in the OSDMap. Exposing 'osd metadata' seems like the simplest thing? sage > Sorry for the link explosion, just trying to carry some context along. Any > (well, most) opinions would be appreciated! > > Joe > > From: Handzik, Joe > Sent: Friday, June 05, 2015 10:28 AM > To: [email protected] > Cc: Dan Mick ([email protected]) > Subject: Thoughts about metadata exposure in Calamari > > Hey guys, > > I finally feel like I have my head wrapped around how this works. I feel like > I have two general paths that I could go down now: > > 1. In calamari, use the 'osd metadata' command to pull the metadata up. The > task here would be to figure out the right way to arrange that data (this > might actually kickoff the start of Gregory's hardware API concept). > a. My concern here is that metadata is a poorly-defined blob of string pairs. > It's not a well-defined structure like some of the other data that is exposed > today via other commands ('osd dump'). > 2. Speaking of 'osd dump', another option would be to make the metadata > bundle a first-class citizen of the dataset that is exposed via 'osd dump'. > This would obviously require changes in OSDMap and probably OSD itself, but > then the data would come along for free via the existing 'osd dump' command. > 3. A hybrid of these two would be to define the metadata via a structure > instead of the set of string pairs that it is today, but still plan to add an > 'osd metadata' call into Calamari like in option #1. > a. This might be the best option, but requires changes in both Ceph and > Calamari. I'd probably make the Ceph changes first, so I don't need to > implement option #1 first and then move something more like #3. > > Lemme know if any of this seems off. No need to reply now, this is intended > as background information to clarify my thought process in the meeting today. > Still waiting on Sage to approve my existing pull request, but after a rocky > hour earlier in the week (hadn't tested -with-debug, apparently), I believe > I'm done. > > Joe > -- > 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 > > -- 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
