Follow up question: 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). Regards, Mandell Degerness On Wed, Aug 1, 2012 at 4:43 PM, Tommi Virtanen <tv@xxxxxxxxxxx> wrote: > On Wed, Aug 1, 2012 at 4:27 PM, Mandell Degerness > <mandell@xxxxxxxxxxxxxxx> wrote: >> As of this time, we are allocating OSD numbers based on servers. The >> "ceph osd create" command seems like it may be useful, but is not >> documented nearly well enough yet. Can someone please provide answers >> to the following: >> >> 1. Is this guaranteed to always produce an OSD number that is unique, >> with no worries about race conditions? > > Yes. > > You can also use "ceph osd create UUID", so it's safe to run multiple > times, get the same result for the same UUID, and not waste numbers. > >> 2. Does this eliminate the need to worry about the value of max_osd? > > It increases max_osd as necessary. > https://github.com/ceph/ceph/blob/master/src/mon/OSDMonitor.cc#L2167 > >> 3. Are there any other side effects of running the command? > > Nope. > > > You may be interested in digging into the mechanics of the new chef > deployment stuff, and "osd hotplugging" as I call it. It completely > automates osd id allocation. > > http://ceph.com/docs/master/install/chef/ > http://ceph.com/docs/master/config-cluster/chef/ > > More architectural docs don't really exist yet, sorry. -- 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
