On Mon, 23 Oct 2017, Wido den Hollander wrote: > > Op 19 oktober 2017 om 15:34 schreef Sage Weil <sage@xxxxxxxxxxxx>: > > > > > > On Thu, 19 Oct 2017, Dan van der Ster wrote: > > > Hi Wido, > > > > > > Unexpected crush location changes can indeed be quite nasty. > > > > > > With this in mind, I wonder if a crush lock would be useful. > > > > > > ceph osd set nocrushchange > > > > > > With that flag set, osds could still go in and out, but crush > > > move/add/remove/etc..., also tunables changes, would be blocked. > > > > The problem I see with this is that it would prevent new OSD additions or > > other changes.. and if you went to unset the flag in order to allow a new > > node to be adjusted or brought online then you might get an avalance of > > blocked changes. > > > > I think what we actually want is a more targetted variation of > > osd_crush_update_on_start that only updates teh location if it has never > > been set (i.e., it is a new osd). Like, osd_crush_update_on_create. Then > > it's left to the admin to move OSDs? > > > > > On Mon, Oct 16, 2017 at 2:02 PM, Wido den Hollander <wido@xxxxxxxx> wrote: > > > > Hi, > > > > > > > > I completely overread this, but I just found out that osd_crush_location_hook was renamed to crush_location_hook in the new config style. > > > > > > > > When upgrading from Jewel to Luminous without touching your configuration OSDs will move to the default CRUSH location due to the hook not being executed. > > > > > > > > Was this an oversight with Luminous or was it intentional? > > > > The implications are an oversight.. I didn't think about customized hooks > > that would get reverted if the config option wasn't changed. Otherwise > > the item in the release notes would have read more like a warning: > > > > * The `osd crush location` config option is no longer supported. Please > > update your ceph.conf to use the `crush location` option instead. > > > > Yes, we probably need a big warning for this in the ReleaseNotes. > > Are you going to make sure it goes in? https://github.com/ceph/ceph/pull/18482 I think we also want to make the old config option work too; that isn't done yet. John, I wonder if it is worth adding an 'alias' mechanism into the options framework, so that all users of the option don't have to check for the old and new? sage -- 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
