Re: ceph-volume questions / enhancements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan,

The documentation portion of this complaint is tracked here:

https://tracker.ceph.com/issues/58354

I will make this change when everyone is back from Christmas break and I can get technical verification from the ceph-volume team for the changes that I'll make.

Zac Dover
Upstream Docs
Ceph Foundation

On Tue, Dec 20, 2022 at 9:00 PM Stefan Kooman <stefan@xxxxxx> wrote:
Hi,

I'm working on some patches to get ceph-volume encryption support some
additional options (related to encryption performance, see: [1]).
While looking into the current code base of ceph-volume, and Ceph
encryption docs [2], it looks like some basic (internal) functionality
is missing, some code is not working (anymore), and the docs are partly
incorrect.

functionality missing: ceph-volume has no code to look up CEPH_MON
config settings, i.e "ceph config get osd param". Instead, at least in
encryption.py, it only checks the ceph config file on disk. I'm pretty
sure this is not sufficient anymore, as operators have started to rely
on the central (mon) config database. Moreover, one of the parameters
you can configure, "osd_dmcrypt_key_size", cannot be set:

ceph config set osd dmcrypt_key_size 256
Error EINVAL: unrecognized config option 'dmcrypt_key_size'

Broken code: One of the current parameters cryptsetup can be fed is
"osd_dmcrypt_key_size". When set however, ceph-volume will throw the
following error:

"TypeError: get_safe() got an unexpected keyword argument 'check_valid'".

See [3] for the LOC. If I remove that check it works and ceph-volume
uses the value from the config file. I can (should?) log a tracker
ticket for this. Apparently nobody is using a non-default key size ...
or using crypto ;-).

Wrong docs: The docs claim "only LUKS (version 1) is used". But this
seems no longer to be true in all cases. Modern distros use LUKS version
2 by default. And ceph-volume encryption.py is not explicitly forcing
the LUKS format version, so the default (2) gets used. That does seem to
work fine however, as I've got a test cluster fully encrypted with LUKS
2 OSDs, see:

cryptsetup luksDump
ceph--e3cf57cd--27dc--4cf2--9784--b2b5198dfcbb-osd--block--5a743d7f--2f60--47da--b9f3--46aa6f5df284
LUKS header information
Version:        2
...

All in all it looks like the ceph-volume code base needs some love :-).
Some functionality, like checking CEPH_MON config variables seems to be
present in cephadm. I'm not sure if cephadm / ceph-volume code can /
should be refactored to have both make use of it? My changes will be
minor, but with ceph-volume in the current state I wonder how to best
proceed.

I would appreciate any comments,

Gr. Stefan

[1]:
https://lists.ceph.io/hyperkitty/list/ceph-users@xxxxxxx/thread/D5URLVPVGX52O6WYV474T6IVTHGHCASB/
[2]: https://docs.ceph.com/en/latest/ceph-volume/lvm/encryption/#
[3]:
https://github.com/ceph/ceph/blob/main/src/ceph-volume/ceph_volume/util/encryption.py#L22
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx

[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux