On 16/10/2018 12:02, Jan Fajerski wrote:
On Mon, Oct 15, 2018 at 06:56:09AM -0500, Alfredo Deza wrote:
On Mon, Oct 15, 2018 at 6:48 AM Jan Fajerski <jfajerski@xxxxxxxx> wrote:
Hi list,
while playing with ceph-volume I noticed that it adds the tag
ceph.data_device
to an lv with the name of the lv (at the time of calling prepare).
I was wondering what this specific tag is used for. From looking at
ceph-volume's code it seems its only ever set.
Using vgrename of lvrename one can easily create an inconsistency in
this
self-reference. Restarting the OSD (or rebooting the node) still
works as
expected but I'm certainly not thinking of all cases here.
The tags are used as a key/value store in the device, and we try to
add as much info there as possible. I think you are right that
we only set it (for now), but I can see how this could get us into
trouble if we ever depended on it.
A similar issue happens with the ephemeral names of other non-lv
devices, in which case we do update them.
If this doesn't serve a specific purpose I think we shouldn't set the
tag (happy
to push a PR).
I think the right thing to do would be to make sure that we have the
right LV and update it if that changes. This would help commands like
`ceph-volume lvm list` which
displays that information.
Would it make sense to change the implementation to simply return the lv
name on the fly instead of duplicating the information in an lvm tag and
trying to keep it consistent?
As starter:
I would consider it ill adviced to start changing these kinds of nameing
in the underlaying storage name....
Just because you can, it is not a reason to do so.
And I do not know enough of LVM, but could this information be used to
restore the correct lv/vg nameing after a serious loss of info about the
LVM layout?
And if you go around "just renaming" you should be knowledgeable to
understand that attributes need to be changed as well.
"It just works" is something I would consider a poor argument for this case.
But that is just me with my BOFH hat on,
--WjW
