Bug #18445
ceph: ping <mon.id> doesn't connect to cluster
0%
Description
I guess no one uses this feature. Misplaced 'connect()' call only applies to mon.* rados/singleton should have caught this, but none of the other suites appear to test cephtool, and workunits/mon/ping.py doesn't test this case
History
#1 Updated by Dan Mick about 7 years ago
- Status changed from 7 to Fix Under Review
#2 Updated by Sage Weil about 7 years ago
- Priority changed from Low to Urgent
#3 Updated by Sage Weil about 7 years ago
- Priority changed from Urgent to Low
#4 Updated by Kefu Chai about 7 years ago
workunits/mon/ping.py does test ceph ping mon.{mon_id}
, see https://github.com/ceph/ceph/blob/master/qa/workunits/mon/ping.py#L79 and https://github.com/ceph/ceph/blob/master/qa/workunits/mon/ping.py#L96
#5 Updated by Dan Mick about 7 years ago
Huh. So it does. I don't understand how both of these haven't just been failing consistently then.
#6 Updated by Dan Mick about 7 years ago
Ah. It depends on how build_initial_monmap works.
In my case, ping mon.<specific> returns ENOENT, which the CLI shows as Error connecting to cluster: ObjectNotFound.
I have a ceph.conf with mon_initial_members and mon_host set, but no monmap; this causes build_initial_monmap to return a monmap with 'noname-a', 'noname-b', etc. set in it; then, MonClient::ping_monitor tries to find a monitor named 'noname-<specific>', which of course fails and returns ENOENT.
Running with a real monmap file fixes this, as does connecting to the cluster first (because then the monmap is 'real', with real names).
#7 Updated by Dan Mick about 7 years ago
#8 Updated by Greg Farnum almost 7 years ago
- Project changed from Ceph to RADOS
- Category changed from ceph cli to Administration/Usability
- Component(RADOS) MonClient added
#9 Updated by Dan Mick over 3 years ago
- Status changed from Fix Under Review to Won't Fix
Long since fixed differently