One of the top questions for ceph-volume has been "why this doesn't create
partitions like ceph-disk does?". Although we have initially focused on LVM,
the same question is true (except for LVs instead of partitions). Now
that ceph-volume is
stabilizing, we can expand on a more user-friendly approach.
We are planning on creating an interface to size devices automatically based on
some simple criteria. There are three distinct use cases that we are going to
support, that should allow easy OSD provisioning with defaults, to more
esoteric use cases with third-party systems (like rook, ceph-ansible, seasalt,
etc...)
This is being implemented as a separate sub-command to avoid pilling up the
complexity on the existing `lvm` one, and reflect the automation behind it.
Here are some examples on how the API is being designed, for fully automatic
configuration, semi-automatic (allows input), and manual via a config
management system:
Automatic (no configuration or options required):
-------------------------------------------------
Single device type:
$ ceph-volume auto
Use --yes to run
Detected devices:
[rotational] /dev/sda 1TB
[rotational] /dev/sdb 1TB
[rotational] /dev/sdc 1TB
Expected Bluestore OSDs:
data: /dev/sda (100%)
data: /dev/sdb (100%)
data: /dev/sdc (100%)
This scenario will detect a single type of unused device (rotational)
so the bluestore
OSD will be created on each without block.db or block.wal
Mixed devices:
$ ceph-volume auto
Use --yes to run
Detected devices:
[rotational] /dev/sda 1TB
[rotational] /dev/sdb 1TB
[rotational] /dev/sdc 1TB
[solid ] /dev/sdd 500GB
Expected Bluestore OSDs:
data: /dev/sda (100%), block.db: /dev/sdd (33%)
data: /dev/sdb (100%), block.db: /dev/sdd (33%)
data: /dev/sdc (100%), block.db: /dev/sdd (33%)
This scenario will detect the unused devices in the system and understand that
there is a mix of solid and rotational devices, will place block on the
rotational ones, and will split the ssd in as many rotational devices found (3
in this case).
Semi configurable outcome, with input:
--------------------------------------
A user might not want to consume the devices that were automatically detected
in the system as free, so the interface will allow to pass these devices
directly as input.
$ ceph-volume auto /dev/sda /dev/sdb /dev/sdc
Device information:
[rotational] /dev/sda 1TB
[rotational] /dev/sdb 1TB
[rotational] /dev/sdc 1TB
Expected Bluestore OSDs:
data: /dev/sda (100%), block.db: /dev/sdd (33%)
data: /dev/sdb (100%), block.db: /dev/sdd (33%)
data: /dev/sdc (100%), block.db: /dev/sdd (33%)
Please hit Enter to continue, or Ctrl-C to cancel
Similarly, for mixed devices:
$ ceph-volume auto /dev/sda /dev/sdb /dev/sdc /dev/sdd
Use --yes to run
Device information:
[rotational] /dev/sda 1TB
[rotational] /dev/sdb 1TB
[rotational] /dev/sdc 1TB
[solid ] /dev/sdd 500GB
Expected Bluestore OSDs:
data: /dev/sda (100%), block.db: /dev/sdd (33%)
data: /dev/sdb (100%), block.db: /dev/sdd (33%)
data: /dev/sdc (100%), block.db: /dev/sdd (33%)
Please hit Enter to continue, or Ctrl-C to cancel
Fully Manual (config management systems):
-----------------------------------------
A JSON file or a blob as a positional arugment would allow fine tunning other
specifics, like using 2 OSDs per NVMe device, determine an exact size for
a block.db or even a block.wal LV.
$ ceph-volume auto /etc/ceph/custom_osd_provisioning.json
Or:
$ ceph-volume auto "{ ... }"
Here the API is still undefined as of now, but the idea is to expand on more
complex setups that can be better managed by configuration management systems
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
