Thanks, that is most useful to know!
The Ceph docs are very good except when they propagate obsolete
information. For example, using "ceph-deploy" on Octopus (my copy
didn't come with ceph-deploy - it used cephadm).
And, alas, nothing has been written to delineate differences between
Just to add a bit more information, the 'ceph daemon' command is still
valid, it just has to be issued inside of the containers:
quincy-1:~ # cephadm enter --name osd.0
Inferring fsid 1e6e5cb6-73e8-11ee-b195-fa163ee43e22
[ceph: root@quincy-1 /]# ceph daemon osd.0 config diff | head
{
OK. Found some loglevel overrides in the monitor and reset them.
Restarted the mgr and monitor just in case.
Still getting a lot of stuff that looks like this.
Dec 19 17:10:51 xyz1.mousetech.com ceph-278fcd86-0861-11ee-a7df-
9c5c8e86cf8f-mon-xyz1[1906961]: debug 2023-12-19T22:10:51.314+
The problem with "ceph daemon" is that the results I listed DID come
from running the command on the same machine as the daemon.
But "ceph tell" seems to be more promising.
There's more to the story, since I tried to do blind brute-force
adjustments and they failed also, but let me see if ceph
"ceph daemon" commands need to be run local to the machine where the daemon
is running. So in this case if you arent on the node where osd.1 lives it
wouldnt work. "ceph tell" should work anywhere there is a client.admin key.
Respectfully,
*Wes Dillingham*
w...@wesdillingham.com
LinkedIn
I would start with "ceph tell osd.1 config diff", as I find that
output the easiest to read when trying to understand where various
config overrides are coming from. You almost never need to use "ceph
daemon" in Octopus+ systems since "ceph tell" should be able to access
pretty much all commands
