Bug #3599
closedmkcephfs should fail out when ceph.conf has an error
0%
Description
In the /etc/ceph/ceph.conf, there was a missing bracket after [mon.b , which did not get caught during mkcephfs. It errors when ceph is started.
ubuntu@burnupi46:/etc/ceph$ sudo service ceph -a start
=== mon.a ===
Starting Ceph mon.a on burnupi46...already running
=== mon.b ===
Starting Ceph mon.b on burnupi47...
unable to read magic from mon data.. did you run mkcephfs?
failed: 'ssh burnupi47 /usr/bin/ceph-mon -i b --pid-file /var/run/ceph/mon.b.pid -c /tmp/ceph.conf.22288 '
To correct the error, I had to stop, delete the contents of the directories at /var/lib/ceph, and rerun mkcephfs.
Updated by Greg Farnum over 11 years ago
mkcephfs is a terrible, terrible thing. You're right that it should, but there are lots and lots of things that it should do. Like support re-running when one of the nodes fails, or cleaning itself up on errors. ceph-deploy is our future.
ceph-deploy may also not detect this (not sure), so if it doesn't deal with that then please generate a bug for ceph-deploy, and perhaps a generic one for all deployment mechanisms. Unless this is a generic problem that gets a generic fix, I'm not sure how easy it will be to fix for mkcephfs directly. (Anybody who does look into this, my guess is that ceph-conf parsing and error codes are the best bet?)
Updated by Sage Weil over 11 years ago
I think the "right" fix here would be for things parsing the conf to generate something on stderr if they see the syntax error. That would be visible (probably several times) from the mkcephfs output, and would point the user in the right direction.
Updated by Sage Weil over 11 years ago
- Status changed from New to In Progress
wip-conf will spam stderr unconditionally about parse errors. There might be other fallout, though, and the behavior doesn't change (it will still continue).
Updated by Sage Weil over 11 years ago
- Status changed from In Progress to Resolved