On Mon, 10 Apr 2017, Loic Dachary wrote: > On 04/10/2017 03:32 PM, Sage Weil wrote: > > On Mon, 10 Apr 2017, Loic Dachary wrote: > >> Hi Sage, > >> > >> When the OSD is prepared, we add a --device-class option to ceph-disk > >> that creates a device_class file and activate can use it use when > >> creating the the OSD[1]. The ceph osd create command is given an > >> additional optional argument (device class). If the device class > >> argument is present, ceph osd create[2] creates a device entry in the > >> crushmap (it currently does nothing with the crushmap) so that the > >> corresponding device class can be preserved. This happens before > >> update_crush_location[3] is called and since the device is not included > >> in any crush tree it won't be used. > >> > >> I'm not happy about adding an argument to osd create. We could instead > >> have a new dedicated command create-with-device-class but I like that > >> even less. We could also add a "ceph osd crush create-device" and have > >> ceph-disk call it right after "ceph osd create", followed by "ceph osd > >> crush set-device-class". That would be my second favorite: the only > >> drawback is having a multi-step device creation during activation but > >> all steps are idempotents that should not be a problem. > >> > >> What do you think ? > > > > We're aiming toward a new osd create command anyway that does all of this > > stuff at once (create osd id and set uuid, set cephx key, set lockbox key > > for dmcrypt, add to crush map). Having it also set the device class seems > > like an easy addition. I believe Joao has started or is about to start > > work on this? > > > > In the meantime, I would do the simplest thing, which is probably just > > calling 'ceph osd crush set-device-class'. It could be done before the > > 'osd crush create-or-move' in OSD::update_crush_location(), > > Does that mean we should have a --device-class argument to ceph-osd --mkfs ? Or is there another way I'm not seeing ? If you're putting a file in the osd_data directory, you can use ObjectStore::read_meta() (and/or write_meta()) to easily access it. Thinking about this a bit more, if the admin has explicitly specified the type like this, I don't think we need to worry about set-but-do-not-change behavior like I suggested below... sage > > > but then we'd > > probably want to make it only set it if a device class isn't already set > > (i.e., don't change it if the admin set it to something else). Or at some > > convenient point during the initial activation that similarly avoids > > clobbering the value if the admin set it... > > > > sage > > > > -- > Loïc Dachary, Artisan Logiciel Libre > >
