Bug #41016
closedImprove upmap change reporting in logs
0%
Description
1. do not silently skip mappings in _apply_upmap() or anywhere else, when they aren't going to be applied
2. maybe_remove_pg_upmaps() should report why upmap mappings are getting removed
Updated by David Zafman over 4 years ago
- Assignee set to David Zafman
The function _apply_upmap() would be getting called very frequently. This makes logging there problematic. Also, one case is transitory (OSD happens to be out). The logging would have to be greater than level 20.
The function maybe_remove_pg_upmaps() is now clean_pg_upmaps(). I see some messages that would be logged (level 0) in the osd's log for errors found in upmaps. Those messages are generated by OSDMap::check_pg_upmaps(). Some of the errors aren't logged, so we could add those.
Updated by David Zafman over 4 years ago
- Status changed from New to In Progress
- Priority changed from Normal to Immediate
- Backport set to nautilus, mimic, luminous
Updated by David Zafman over 4 years ago
We aren't going to add logging to _apply_upmap() because it is invasive to get a CephContext into that function to be able to log.
Updated by David Zafman over 4 years ago
- Status changed from In Progress to Pending Backport
Updated by David Zafman over 4 years ago
- Copied to Backport #43650: nautilus: Improve upmap change reporting in logs added
Updated by David Zafman over 4 years ago
- Copied to Backport #43651: luminous: Improve upmap change reporting in logs added
Updated by David Zafman over 4 years ago
- Copied to Backport #43652: mimic: Improve upmap change reporting in logs added
Updated by Nathan Cutler about 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".