On Wed, 23 Jan 2019 08:11:31 -0500
Alfredo Deza <adeza@xxxxxxxxxx> wrote:
> I don't know how that would look like, but I think it is worth a try
> if re-deploying OSDs is not feasible for you.
yes, is there a working way to migrate this I will have a try it.
>
> The key api for encryption is *very* odd and a lot of its quirks are
> undocumented. For example, ceph-volume is stuck supporting naming
> files and keys 'lockbox'
> (for backwards compatibility) but there is no real lockbox anymore.
> Another quirk is that when storing the secret in the monitor, it is
> done using the following convention:
>
> dm-crypt/osd/{OSD FSID}/luks
>
> The 'luks' part there doesn't indicate anything about the type of
> encryption (!!) so regardless of the type of encryption (luks or
> plain) the key would still go there.
>
> If you manage to get the keys into the monitors you still wouldn't be
> able to scan OSDs to produce the JSON files, but you would be able to
> create the JSON file with the
> metadata that ceph-volume needs to run the OSD.
I think it is not that problem to create the json files by myself.
Moving the Keys to the monitors and creating appropriate auth-keys
should be more or less easy as well.
The problem I see is, that there are individual keys for the journal
and data partition while the new process useses only one key for both
partitions.
maybe I can recreate the journal partition with the other key. But is
this possible? Are there important data ramaining on the journal after
clean stopping the OSD which I cannot throw away without trashing the
whole OSD?
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
