Conversation
|
note before: this has not gone through any teuthology run yet. I have not run a manual upgrade test yet, and I'm a bit concerned it will not make it on the first try -- although I expect it to work if the peons are the first to be upgraded. |
|
is this backward compatible ? |
|
@dachary I think so but not in a way I'm absolutely comfortable with. I'll rework this patch later today. |
|
repushed a saner approach |
|
@jecluis LGTM |
|
@jecluis could you link the successfull mon suite run you scheduled from here for archival purposes ? |
|
@dachary Haven't scheduled a run on this yet. Trying to avoid wasting resources on something that seems a bit controversial -- and thus has higher probability of being scrapped. |
|
lgtm. looks like i need to revise my "mon_metadata" to move it into the herd of mon commands. |
|
@tchaikov I would think that if both end up being merged in the same dev release, and your 'mon_metadata' pull request is merged before this one, we could simply change your command without the need to deprecate it. I may be wrong here, but I think that such a change would not leak outside the dev release. |
|
oh, thanks. that's a relief. =) |
|
rebased on top of current master and changed @tchaikov's 'mon_metadata' to 'mon metadata' (see last patch of the series) |
|
Reviewed-by: |
|
mds cluster_down |
|
rebase on top of current master |
This allows us to do nifty stuff like 'FLAG(foo) | FLAG(bar)' and expand it to (MonCommand::FLAG_foo | MonCommand::FLAG_bar), instead of being bound by a single flag on macro expansion. Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes much more sense if we're OR'ing flags. Or not as weird. Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Instead of passing '0' for commands without flags, pass FLAG_NONE instead. It's prettier and more obvious -- and it only costs 64 bits. Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Otherwise it's virtually impossible to change a command's help string without triggering a mismatch with the leader's command set. Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes it easier to identify the command as being related with the monitor instead of cluster-wide. This entails adding an exception to module 'mon' in order to have this command handled by the Monitor class instead of MonmapMonitor (which is the one traditionally handling 'mon' module commands). Fixes: #11545 Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes it easier to identify the command as being related with the monitor instead of cluster-wide. This entails adding an exception to module 'mon' in order to have this command handled by the Monitor class instead of MonmapMonitor (which is the one traditionally handling 'mon' module commands). Fixes: #11545 Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes it easier to identify the command as being related with the monitor instead of cluster-wide. This entails adding an exception to module 'mon' in order to have this command handled by the Monitor class instead of MonmapMonitor (which is the one traditionally handling 'mon' module commands). Fixes: #11545 Signed-off-by: Joao Eduardo Luis <joao@suse.de>
'ceph mon_metadata' was added still during this dev cycle, so there is no need to deprecate it first. Fixes: #11545 Signed-off-by: Joao Eduardo Luis <joao@suse.de>
mon: have mon-specific commands under 'mon' module
|
merged manually |
quote from Sage's reply > This is a mon-specific command--it doesn't make sense as a CLI command > for the entire cluster--it only makes sense as a command to tell a > specific monitor. Like ``ceph tell mon.a compact``. Back when Joao > did ceph#4595 these commands were all mixed together and putting it under > 'ceph mon ...' made sense, but now you're specifially sending it to a > mon, so the 'mon' part of the command is redundant. so let's drop "mon compact" in favor of "compact" command Signed-off-by: Kefu Chai <kchai@redhat.com>
quote from Sage's reply > This is a mon-specific command--it doesn't make sense as a CLI command > for the entire cluster--it only makes sense as a command to tell a > specific monitor. Like ``ceph tell mon.a compact``. Back when Joao > did ceph#4595 these commands were all mixed together and putting it under > 'ceph mon ...' made sense, but now you're specifially sending it to a > mon, so the 'mon' part of the command is redundant. so let's drop "mon compact" in favor of "compact" command Signed-off-by: Kefu Chai <kchai@redhat.com>
4 participants
e.g., instead of having 'ceph scrub' or 'ceph sync force', have instead
'ceph mon scrub' and 'ceph mon sync force'. Makes more sense and avoids
confusing the user about what component of ceph is being synchronized or
scrubbed.
Fixes: #11545
Signed-off-by: Joao Eduardo Luis joao@suse.de