Bug #4752
closed
ceph-create-keys doesn't work on upgraded clusters
Added by Greg Farnum about 11 years ago.
Updated about 11 years ago.
Description
ceph-create-keys requires the "mon." key to have permission to do things to the monitors. Apparently older deployments leave mon. blank, while new ones give it these permissions.
Unfortunately, that means an upgrade from bobtail to cuttlefish leaves ceph-create-keys trying to run, and failing each time. I believe it loops attempting to succeed, which means unending spam to the monitor logs, as well as processes that never go away (which pile up if you restart your monitors, for instance).
I'm setting this to Urgent since we've seen several reports from early upgraders and I think it's going to hit everybody who does so.
oops, i dropped this ball.
ceph command was update dto return the error code, so it just need sto check if $! is EACCES/EPERM vs something else and exit gracefully instead of looping.
Ah. Well that seems easy enough.
- Priority changed from Normal to Urgent
- Status changed from New to In Progress
ceph CLI currently fails in ceph_tool_common_init and doesn't pass back a failure code that can be interpreted, so return is always 1. That'll need fixing.
- Status changed from In Progress to Resolved
Further update from Dan indicated that EACCES was returned on authentication error after all. I tested the changes by stopping the monitor, setting the keyring cap filed to blank and restarting. Ceph-disk-create exited with error message.
Resolved with the following commit to next branch:
commit 1a8b30eff1c7336607872eb41113539ff8817a01
Author: Gary Lowell <glowell@inktank.com>
Date: Fri Apr 19 11:19:05 2013 -0700
ceph-create-keys: Don't wait if permission denied
If get or create keys returns permssion denied, exit
gracefully instead of retrying.
Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Also available in: Atom
PDF