Ceph » Orchestrator

Currently Orchestrator is unable to use a device that LVM has already been initialized at. As a result:

1) User to unable put more DB/WAL volume(s) to this device for additionally (at Day 2+ operation) deployed OSD. Please note that DB/WAL volumes tend to have limited size of specific granularity and hence underlying disk tend to have plenty of spare space.
2) User is unable to put additional OSD to partially utilized drive. E.g. one might want to use part of fast NVMe drive to keep DB/WAL volumes for multiple slow OSDs and use the rest available NVMe space for another "fast" OSD.
3) One can get invalid OSD layout when user redeploys OSDs using existing running orchestrator OSD deployment service (aka applied device group). E.g. user has such a service which is able to deploy a bunch of OSDs at specific node. This service deploys multiple "per-spinner" OSDs backed by a single SSD drive as a DB volume. This works fine for the first time: OSDs 1,2,3 are deployed using /dev/sdb,/dev/sdc,/dev/sde paths as main devices and /dev/nvme0n1 as a shared drive for DB volumes. Then one wants to redeploy all (or part) of these OSDs and removes them via 'ceph orch osd rm" and proceeds with "ceph orch zap". At this point the order of "zapping" is important (which is absolutely unclear to user). If user zaps /dev/nvme0n1 first and then proceeds with zapping /dev/sdb(c,d) he might get first OSD deployed with DB volume while others will lack it. The root cause is that orchestrator starts OSD deployment when /dev/sdb is unzapped (but /dev/sdc and /dev/sdd aren't) and prevents /dev/nvme0n1 usage for other OSDs.