Uploaded image for project: 'openATTIC'
  1. openATTIC
  2. OP-1317

Create a better CRUSH map editor

    XMLWordPrintable

    Details

    • Type: Epic
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Epic Name:
      Nodb-Ceph-CRUSH-Map-Editor
    • Epic Status:
      To Do
    • External issue ID:
      fate#322428

      Description

      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.

      General design goals

      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.

      See also: OP-86

      Auto generation of the CRUSH map

      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.

      Data sources

      • osd crush dump
      • salt '*' ceph.osd_discover
      • Users will eventually create CRUSH map that cannot be rendered. We need to abort then!

      Existing code

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              swagner Sebastian Wagner
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: