config-key layout

config-key is a general-purpose key/value storage service offered bythe mons. Generally speaking, you can put whatever you want there.Current in-tree users should be captured here with their key layoutschema.

OSD dm-crypt keys

Key:

  1. dm-crypt/osd/$OSD_UUID/luks = <json string>

The JSON payload has the form:

  1. { "dm-crypt": <secret> }

where the secret is a base64 encoded LUKS key.

Created by the ‘osd new’ command (see OSDMonitor.cc).

Consumed by ceph-volume, and similar tools. Normally access to thedm-crypt/osd/$OSD_UUID prefix is allowed by a client.osd-lockbox.$OSD_UUIDcephx key, such that only the appropriate host can retrieve the LUKS key (whichin turn decrypts the actual raw key, also stored on the device itself).

ceph-mgr modules

The convention for keys is:

  1. mgr/$MODULE/$option = $value

or:

  1. mgr/$MODULE/$MGRID/$option = $value

For example,:

  1. mgr/dashboard/server_port = 80
  2. mgr/dashboard/foo/server_addr = 1.2.3.4
  3. mgr/dashboard/bar/server_addr = 1.2.3.5

Configuration

Configuration options for clients and daemons are also stored in config-key.

Keys take the form:

  1. config/$option = $value
  2. config/$type/$option = $value
  3. config/$type.$id/$option = $value
  4. config/$type.$id/$mask[/$mask2...]/$option = $value

Where

  • type is a daemon type (osd, mon, mds, mgr, client)

  • id is a daemon id (e.g., 0, foo), such that $type.$id is something like osd.123 or mds.foo)

  • mask restricts who the option applies to, and can take two forms:

    • $crush_type:$crush_value. For example, rack:foorack

    • class:$classname, in reference to CRUSH device classes (e.g., ssd)