Project

General

Profile

Feature #42502

Support logical devices in `lvm prepare --data <device path>`

Added by Satoru Takeuchi 11 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

`ceph-volume lvm prepare --data <device path>` only accepts physical block
devices and partitions.

It will be convenient to support other kinds of devices.

Possible use cases are as follows:
- With dm-fleakey, we can simulate the failure of devices in testing.
- With dm-crypt, we can use encrypted devices with a variety of
encryption methods.
- With LVs in the form of device path, orchestration software,
e.g. Rook, can pass LVs transparently like other devices.

History

#1 Updated by Jan Fajerski 11 months ago

This is already supported. You can pass an lv to the lvm create or lvm prepare subcommands like so:

ceph-volume lvm prepare --data <vg_name>/<lv_name>

Does this not work for you? If so can you please open a bug and add a debug log?

#2 Updated by Satoru Takeuchi 11 months ago

This is already supported. You can pass an lv to the lvm create or lvm prepare subcommands like so:

ceph-volume lvm prepare --data <vg_name>/<lv_name>

Oops, probably my expression, `logical devices` was improper.

What I mean and what I'm preparing PR to are as follows.

  1. a. Support devices created by device-mappers

Let assume that we want to use a device created with dm-flakey as OSD.
When we call `ceph-volume lvm prepare --data <path/to/device`,
it fails since the following condition A becomes false.

https://github.com/ceph/ceph/blob/70d27ce3523738c9363760d33d819bf48342b9fe/src/ceph-volume/ceph_volume/devices/lvm/prepare.py#L192
```
def prepare_device(self, arg, device_type, cluster_fsid, osd_fsid):
<snip>
if disk.is_partition(arg) or disk.is_device(arg): ... condition A # we must create a vg, and then a single lv
vg = api.create_vg(arg)
lv_name = "osd-%s-%s" % (device_type, osd_fsid)
return api.create_lv(
lv_name,
vg.name, # the volume group
tags={'ceph.type': device_type})
else:
error = [
'Cannot use device (%s).' % arg,
'A vg/lv path or an existing device is needed']
raise RuntimeError(' '.join(error))

```

I know multiple devices are not supported as-is.
https://docs.ceph.com/docs/mimic/ceph-volume/lvm/prepare/#multipath-support

However, the above-mentioned condition A prohibits not only multipath
devices (lsblk's TYPE=="mpath"), but also all device excepts physical
devices and partitions thereof (TYPE == "disk" or "part").
It's a too strong restriction.

  1. b. Passing LV to ceph-volume transparently

Currently, we can pass LV to ceph-volume with `vg_name/lv_name` as you said.
In addition to this way, it's convenient to be able to pass it with a device
name because users can manage LVs and other devices transparently.

If I should divide this issue to two different ones, I'll do it.

#3 Updated by Jan Fajerski 11 months ago

Regarding multipath: I'm actually exploring that too. I believe this should work fine (I need a test system) when you simply create block device nodes for your mpath device. It would be up to the admin to make sure that multipath is set up as expected.

The second use case (passing an LV by a device node) I'm not sure what the advantage is. You should be able to pass any LV by <vg_name>/<lv_name>, what does the option to pass an LV by dev/<some_name> add here?

#4 Updated by Satoru Takeuchi 11 months ago

Regarding multipath: I'm actually exploring that too. I believe this should work fine (I need a test system)
when you simply create block device nodes for your mpath device. It would be up to the admin to make sure
that multipath is set up as expected.

Got it.

In the PR that I've created, mpath type is intentionally rejected.
Do you mean that mpath should also be permitted? In other words,
permitting all types of block devices is more preferable than the current
implementation?

The second use case (passing an LV by a device node) I'm not sure what the advantage is.
You should be able to pass any LV by <vg_name>/<lv_name>, what does the option to pass
an LV by dev/<some_name> add here?

It's not a kind of must-have feature, but for a little convenience.
From the perspective of Ceph orchestration tools like Rook, its users will
specify the devices for OSD as /path/to/device without the knowledge of device type.

Anyway, this LV topic is a bit different from the first topic. So I withdraw this topic
from this issue. I'm sorry to confuse you.

#6 Updated by Satoru Takeuchi 11 months ago

As I wrote in the following PR, the scope of this issue is too wide.
I'll close this ticket and will reconsider the use case of individual
block device type.

https://github.com/ceph/ceph/pull/31205#issuecomment-552042462

#7 Updated by Satoru Takeuchi 11 months ago

I seem not to have enough privilege to change the status of this ticket.
Could you close it? I'm sorry to bother you.

#8 Updated by Nathan Cutler 10 months ago

  • Status changed from New to Closed

Also available in: Atom PDF