When reviewing the existing SQL-based CRUSH map editor, it turned out that it is easy to make mistakes there. We should aim for a user-friendly editor instead.
Maybe handling one aspect of the crush map at a time, instead of providing everything in one editor.
For example, the failure domain should be a slider on top of a root and each root could be displayed as an independent tab. In general, roots are often related to different hardware types, for example all SSDs would end up in one root.
Don't let users to set the failure domain to "osd", cause this doesn't make much sense. In general, the falliere domain should be set per root, possibly by using a slider per root.
Instead of forcing users to manually modify the crush map, we could also auto generate the crush map for typical setups:
- Parts of the CRUSH map could be generated from salt using templates, as salt knows the hard drive types.
- If you have 50 similar machines, one expect them to be grouped by hardware configuration. Which is available using the Ceph salt integration.
- After an osd gets created, we could use ceph osd crush ... for putting it into the appropriate node or root.
- Thus, Make the CRUSH map a part of the osd deployment step.
- osd crush dump
- salt '*' ceph.osd_discover
- Users will eventually create CRUSH map that cannot be rendered. We need to abort then!
Replacing the existing Editor doesn't mean to throw away all existing code. Especially the tree should also be used. Thus, the API should be similar to the existing API.
|CRUSH map editor: physical view does not display OSDs||Open||Unassigned|