Storage: Align Ceph block device name encoding #14807
Conversation
Different calls of these functions are currently using both senses of volume: - A Ceph block device (RBD Image) - A LXD storage volume Because a disk device can specify an RBD image as "ceph:<pool_name>/<volume_name>", we'll go for the first meaning; the name passed to these functions should be the name of a RADOS block device (RBD image), not a LXD storage volume. These functions should (in future) be replaced with a more comprehensive abstraction for what "MountInfo" is currently doing. This serialization is not written anywhere, it's just deserialized when it gets to the instance driver. Signed-off-by: Wesley Hershberger <[email protected]>
MggMuggins
changed the title
MggMuggins
changed the title
MggMuggins
changed the title
There was a problem hiding this comment.
I agree wrt to the future plans to change how mount info from a disk device is passed to an instance driver. Its gotten rather complicated and obtuse over the years with per-device custom encoding options.
I'd prefer to see us return different concrete struct types, via interface smuggling using any, and then use type assertion in the instance drive to detect the type of struct returned and therefore know which type of disk it is and have access to the custom fields required for that disk type without needing to encode/decode.
When support for using qemu's ceph support was added, this blurred the lines between responsibility of each subsystem.
Before that it was the disk device's responsibility to activate and mount the volume and then pass that mount path/block path to the instance driver.
But after that it became the instance driver's job to know all of the details required to activate the ceph volume.
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
MggMuggins
force-pushed
the
fix-ceph-rbd-root-disk-attachment
branch
from
1fd3e44 to
12fc51a
Compare
2 participants
Different calls of
DiskGetRBDFormatandDiskParseRBDFormatare currently using both senses of "volume":Because a disk device can specify an RBD image with source
ceph:<pool_name>/<volume_name>", these functions should use the first meaning: the name passed should be the name of a RADOS block device (RBD image), not a LXD storage volume.These functions should (in future) be replaced with a more comprehensive abstraction for what
MountInfo.DevPathis currently doing. This serialization doesn't seem to be written anywhere, it's just deserialized when it gets to the instance driver.This fixes the failures from canonical/lxd-ci#366; the QEMU driver was inferring a virtual-machine
VolumeTypeonly whenTargetPath == "/"