Re: Unknown daemon type ceph-exporter
On Thursday, June 25, 2026 9:22:58 AM Eastern Daylight Time Eugen Block via ceph-users wrote:
Hi,
is this a known issue that ceph-exporter is not recognized by cephadm?
host1:~ # cephadm --image ceph:v20.2.2 ls | jq -r '.[] | select(.name=="ceph-exporter.host1") | "\(.name) \(.version)"' version for unknown daemon type ceph-exporter ceph-exporter.host1 null
I don't see it in the daemon_types listed here:
https://github.com/ceph/ceph/blob/main/src/cephadm/cephadmlib/listing_update rs.py
The issue is that a lot of things in cephadm are implemented as a sequence of if statements (per service or service type) and as opposed to using common interfaces and so if something is forgotten or overlooked in the sequence of ifs it fails. Other parts of cephadm should handle ceph-exporter fine, it's just that this version gathering function doesn't handle it properly. It's a bug, please file a tracker.
And one more thing: why is the version empty in 'cephadm ls' output while 'ceph orch ps' is capable of recognizing the version:
host1:~ # ceph orch ps --daemon-type ceph-exporter -f json | jq -r '.[] | select(.daemon_name=="ceph-exporter.host1") | "\(.version)"' 20.2.2
I'm not sure about this but it's clearly part of the bug where the system is following different code paths.
Thanks, I created this: https://tracker.ceph.com/issues/77732 Zitat von John Mulligan <phlogistonjohn@asynchrono.us>:
On Thursday, June 25, 2026 9:22:58 AM Eastern Daylight Time Eugen Block via ceph-users wrote:
Hi,
is this a known issue that ceph-exporter is not recognized by cephadm?
host1:~ # cephadm --image ceph:v20.2.2 ls | jq -r '.[] | select(.name=="ceph-exporter.host1") | "\(.name) \(.version)"' version for unknown daemon type ceph-exporter ceph-exporter.host1 null
I don't see it in the daemon_types listed here:
https://github.com/ceph/ceph/blob/main/src/cephadm/cephadmlib/listing_update rs.py
The issue is that a lot of things in cephadm are implemented as a sequence of if statements (per service or service type) and as opposed to using common interfaces and so if something is forgotten or overlooked in the sequence of ifs it fails. Other parts of cephadm should handle ceph-exporter fine, it's just that this version gathering function doesn't handle it properly. It's a bug, please file a tracker.
And one more thing: why is the version empty in 'cephadm ls' output while 'ceph orch ps' is capable of recognizing the version:
host1:~ # ceph orch ps --daemon-type ceph-exporter -f json | jq -r '.[] | select(.daemon_name=="ceph-exporter.host1") | "\(.version)"' 20.2.2
I'm not sure about this but it's clearly part of the bug where the system is following different code paths.
I think my bug report is invalid, I hadn't noticed the outdated local cephadm package. Zitat von Eugen Block <eblock@nde.ag>:
Thanks, I created this:
https://tracker.ceph.com/issues/77732
Zitat von John Mulligan <phlogistonjohn@asynchrono.us>:
On Thursday, June 25, 2026 9:22:58 AM Eastern Daylight Time Eugen Block via ceph-users wrote:
Hi,
is this a known issue that ceph-exporter is not recognized by cephadm?
host1:~ # cephadm --image ceph:v20.2.2 ls | jq -r '.[] | select(.name=="ceph-exporter.host1") | "\(.name) \(.version)"' version for unknown daemon type ceph-exporter ceph-exporter.host1 null
I don't see it in the daemon_types listed here:
https://github.com/ceph/ceph/blob/main/src/cephadm/cephadmlib/listing_update rs.py
The issue is that a lot of things in cephadm are implemented as a sequence of if statements (per service or service type) and as opposed to using common interfaces and so if something is forgotten or overlooked in the sequence of ifs it fails. Other parts of cephadm should handle ceph-exporter fine, it's just that this version gathering function doesn't handle it properly. It's a bug, please file a tracker.
And one more thing: why is the version empty in 'cephadm ls' output while 'ceph orch ps' is capable of recognizing the version:
host1:~ # ceph orch ps --daemon-type ceph-exporter -f json | jq -r '.[] | select(.daemon_name=="ceph-exporter.host1") | "\(.version)"' 20.2.2
I'm not sure about this but it's clearly part of the bug where the system is following different code paths.
participants (2)
-
Eugen Block
-
John Mulligan