We're running Argonaut and it only has the OSD id in the whoami file and nothing else.
-Mandell On Mon, Aug 20, 2012 at 1:37 PM, Tommi Virtanen <[email protected]> wrote: > 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
