mon/OSDMonitor: fix safety/idempotency of {set,rm}-device-class
If the command is resent (e.g., due to network reconnect), the second
instance may find that the pending crush map already has the changes
and not wait for it to commit.
Note that the stderr message will be misleading in this case; that is a
problem with most of our mon commands. :(
Fixes: https://tracker.ceph.com/issues/49212
Signed-off-by: Sage Weil <sage@newdream.net>
(cherry picked from commit
db6c8f9ab32a7bc0dc8bca94f79812bfb9e7b123)
Conflicts:
src/mon/OSDMonitor.cc
only because mon. in master is mon-> in octopus