On Mon, Aug 20, 2012 at 1:30 PM, Mandell Degerness <[email protected]> wrote: > Is there now, or will there be a migration path that works to add > existing OSDs to the function such that future calls to "ceph osd > create <uuid>" return the current OSD number used in an existing > configuration? I am content if it is an undocumented hack that I can > run on each OSD to register the information with the monitors (I am > assuming that is where the correlation is stored).
Hmm. My understanding is that OSDs have had the uuid for a while, and are submitting it to be part of the osdmap, so that *should* just start working right if you're running recent code. It's stored in the "whoami" file in the osd_data dir. Pick an OSD, cat its whoami file, run "ceph osd create <uuid>", and if you get back an id that doesn't match with what that osd was, say oops and "ceph osd rm <new_bad_id>". -- 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
