On Tue, Mar 27, 2012 at 12:40, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> Two thoughts: >> >> 1. I suspect that some small changes to the bootstrap procedure could >> result in a more streamlined process: >> >> - OSDs stop being responsible for generating their own keys. >> Their keys are instead generated by a MON node and are stored in >> the MON cluster. As a result, the problem to be solved changes: >> >> * before, an OSD needed to have the necessary privileges to >> update the cluster-wide configuration; >> * now, the MON node only needs to have the necessary privileges >> to install an OSD's secret key on that OSD's host. Perhaps, but the devil is in the details. In general, there is no single mon node, any assumption of such is unwanted. With Chef or similar automation software. the monitors do not know when a new OSD is being set up; they cannot easily initiate actions at that time. Triggering actions from the storage node is just easier. The bootstrap key mechanism is not perfect, but it plays well with the limitations of Chef, and it works. Once the rest reaches a similar level of functionality, I'll happily revisit it, but for now it's plenty fine. -- 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
