Dear Greg,
Am 30.11.18 um 18:38 schrieb Gregory Farnum:
> I’m pretty sure the monitor command there won’t move intermediate buckets
> like the host. This is so if an osd has incomplete metadata it doesn’t
> inadvertently move 11 other OSDs into a different rack/row/whatever.
>
> So in this case
I’m pretty sure the monitor command there won’t move intermediate buckets
like the host. This is so if an osd has incomplete metadata it doesn’t
inadvertently move 11 other OSDs into a different rack/row/whatever.
So in this case, it finds the host osd0001 and matches it, but since the
crush map a
Dear Cephalopodians,
sorry for the spam, but I found the following in mon logs just now and am
finally out of ideas:
--
2018-11-30 15:43:05.207 7f9d64aac700 0 mon.mon001@0(leader) e3 handle_command mon_comma
Dear Cephalopodians,
further experiments revealed that the crush-location-hook is indeed called!
It's just my check (writing to a file in tmp from inside the hook) which somehow failed.
Using "logger" works for debugging.
So now, my hook outputs:
host=osd001 datacenter=FTD root=default
as expla
Dear Cephalopodians,
I'm probably missing something obvious, but I am at a loss here on how to
actually make use of a customized crush location hook.
I'm currently on "ceph version 13.2.1" on CentOS 7 (i.e. the last version
before the upgrade-preventing bugs). Here's what I did:
1. Write a sc
