Okay, now I feel stupid but you helped pointing me to my mistake :-D
While collecting the CLI output you mentioned I noticed that the disks
have different sizes, the one I wanted to replace was only 15GB
instead of 20GB as my drivegroup requires. Thanks for pointing that
out, I have no
so "ceph osd tree destroyed -f json-pretty" shows the nautilus2 host with
the osd id you're trying to replace here? And there are disks marked
available that match the spec (20G rotational disk in this case I guess) in
"ceph orch device ls nautilus2"?
On Mon, Feb 20, 2023 at 10:16 AM Eugen Block
I stumbled upon this option 'osd_id_claims' [2], so I tried to apply a
replace.yaml to redeploy only the one destroyed disk, but still
nothing happens with that disk. This is my replace.yaml:
---snip---
nautilus:~ # cat replace-osd-7.yaml
service_type: osd
service_name: osd
placement:
I haven't looked too closely for open tracker issues regarding
ceph-volume, to be honest. I'm still not even sure if I'm doing
something wrong or if it's an actual ceph issue. I still have a couple
of OSDs left to play around in this cluster. So I tried it with a
different OSD, it is
For reference, a stray daemon from cephadm POV is roughly just something
that shows up in "ceph node ls" that doesn't have a directory in
/var/lib/ceph/. I guess manually making the OSD as you did means that
didn't end up getting made. I remember the manual osd creation process (by
manual just
Thanks, Adam.
Providing the keyring to the cephadm command worked, but the unwanted
(but expected) side effect is that from cephadm perspective it's a
stray daemon. For some reason the orchestrator did apply the desired
drivegroup when I tried to reproduce this morning, but then again
Going off of
ceph --cluster ceph --name client.bootstrap-osd --keyring
/var/lib/ceph/bootstrap-osd/ceph.keyring osd tree -f json
you could try passing "--keyring -- lvm create'. I'm guessing it's trying to run the
osd tree command within a container and I know cephadm mounts keyrings
passed to
