On Tue, Jul 3, 2018 at 12:52 PM, Erwan Velu <evelu@xxxxxxxxxx> wrote: >>This is actually not that difficult, and it is what ceph-volume does >>to scan ceph-disk OSDs: >> * look if device has partitions, if it does see if any label is 'ceph data' >> * pass the 'ceph data' partition to `ceph-volume simple scan --stdout` to scan all the important bits from the OSD > > This doesn't support listing journal that doesn't have an associated data disk and we need being able to detect left-over journals for cleaning them. > > erwan@mr-meeseeks:~$ sudo ceph-volume simple scan /dev/sdb1 > --> RuntimeError: Device must be the data partition, but got: ceph journal > > On my setup I have the following output : > erwan@mr-meeseeks:~$ sudo ceph-volume simple scan /dev/sdd1 > Running command: /usr/sbin/cryptsetup status /dev/sdd1 > stderr: Device sdd1 not found > --> RuntimeError: OSD files not found, required "keyring" file is not present at: /var/lib/ceph/tmp/mnt.vxqI3F > My example showed looking for the data label. These reported errors are fine. > >>This is not that easy, and yes, it has dependencies (ceph-detect-init >>is one of them). Which would mean that the single main.py file would not work without it > > We don't need ceph-detect-init as we only need the list option. So let's remove the deps here. Right, that is what I am saying: we would need to remove the dependencies > >>This is also a lot of very complicated work. To add it back there are >>lots of places where it needs to be added, it isn't just a matter of >>adding a single line in the spec file. For example >>our packaging rules require executables to have a man page. Adding the >>man page needs other packaging rules, and adding back the ceph-disk >>man page and altering the CmakeList files >>that include that. > > There is already several binaries that doesn't have an associated man page. > If that would be the last blocking point, I'll handle that workload. I was just giving one example of the many things it would involve to bring back ceph-disk > >>> * add a disclaimer banner explaining the new purpose of the tool during each execution so users won't be confused >>> >>> That would guarantee the same behavior as we had before the removal and avoid a rewriting effort trying to match all the features. >>> The actual ceph-volume implementation doesn't guarantee the coverage we have in ceph-disk for these legacy setups. > >>And I would disagree here, because ceph-volume does work with >>ceph-disk OSDs, for bluestore and filestore, and for plain and LUKS >>dmcrypt setups. > > You cannot detect foreign (unmounted) or not related partitions like a left over wal or journal. The ceph-volume tool doesn't need to detect these types of devices. Other tools that may want to can just list the labels as I showed in my example if they so wish to detect astray partitions > Your ceph_disk_guids structure (from master) counts 10 entries. > ceph_disk code is featuring 40 different types (22 ready, 18 tobe). That mapping is there just for dmcrypt detection, other mappings aren't needed to detect a ceph-disk OSD in ceph-volume's code. > I can agree that ceph_disk was not beloved but for a support perspective, I prefer using the original tooling to insure the same coverage. > Every missing here will lead to a support case that we'll have to handle. I will let others give their opinion here, I am not sure that a simple lsblk call and passing a data partition to ceph-volume so that it can scan is more work than adding ceph-disk back > > So on my side, the balance between taking some short to reintroduced the needed feature and taking the risk of a partial re-implementation is clearly in favor of the first one. -- 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
