Fix #4635
mon: many ops expose uncommitted state
0%
Description
The prepare_update() methods are tricky because they need to make changes relative to uncommitted (pending) state. If they are a noop based on that state, they need to still wait for a commit, even though they aren't making an additional change. This isn't handled correctly in many of the OSDMonitor CLI commands... osd rm, osd crush rm to name just two.
A simple pattern that might make it easy to catch this is for a r=0 value at the end of the function to wait for a commit.
Related issues
Associated revisions
mon: OSDMonitor: don't expose uncommitted state on 'osd crush link'
Fixes: #4635
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: OSDMonitor: don't expose uncommitted state on 'osd crush add/set'
Fixes: #4635
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Merge pull request #507 from ceph/wip-4635.master
Bunch of tidying up on monitor services & fix #4635
Reviewed-by: Sage Weil <sage@inktank.com>
History
#1 Updated by Sage Weil almost 10 years ago
- translation missing: en.field_story_points set to 8.00
#2 Updated by Sage Weil over 9 years ago
- Target version set to v0.68
#3 Updated by Sage Weil over 9 years ago
- Status changed from New to 12
- Source changed from Development to Q/A
teuthology-2013-08-02_01:00:11-rados-next-testing-basic-plana/93344 for a recent occurance
#4 Updated by Joao Eduardo Luis over 9 years ago
- Assignee set to Joao Eduardo Luis
#5 Updated by Joao Eduardo Luis over 9 years ago
We've fixed a couple of cases on the OSDMonitor and merged them into master. I'll keep this open for a while longer while I check for other potential cases and will close it if I find none.
#6 Updated by Sage Weil over 9 years ago
- Status changed from 12 to In Progress
#7 Updated by Sage Weil over 9 years ago
- Target version changed from v0.68 to v0.68 - continued
#8 Updated by Sage Weil over 9 years ago
- Status changed from In Progress to Resolved