curtin-dev team mailing list archive

[Michael Hudson-Doyle <mwhudsonlp@xxxxxxxxxxx>]

> > Michael Hudson-Doyle (mwhudson) wrote 6 minutes ago:
> > I'm not sure what "really disks" means on a philosophical level <wink> but
> yes
> 
> Maybe I'm missing the <wink> here, but just for the folks following along I'll
> be explicit.

Well mostly I'm just being a bit silly.

> I'm referring to multipath partitions which a linear mapping to offsets on the
> multipath path disk in the device-mapper table.   Device-mapper will create
> additional device-mapper devices (/dev/dm-1, /dev/dm-2) which according to
> sysfs, udev and any other linux tool, are of type disk.  For example, in sysfs
> /sys/class/block/dm-1 can be a "partition" and /sys/class/block/dm-1/partition
> will not exist.

Yeah, although I suspect their classification as "disk" is more by default vs them having any better classification.

> The mutipath software stack has conventions to determine which dm devices are
> representing partitions by exporting values like DM_PART and prefixing dm
> names with part- ; etc.

Yeah, I think it's worth saying that these conventions are pretty baked-in: none of it is enforced (afaict) by the kernel or anything, but if you try to set up a multipath device with a device mapper "uuid" that does not start with "mpath-", you're going to have a bad time.

It's a bit frustrating in a way that this information gets spread around so much -- most of this stuff is encoded by multipathd into the dm "uuid" and then read out of the uuid again by 11-dm-mpath.rules / kpartx_id. It's a bit hard to know which information source to treat as canonical. Probably reading things from udev is the right level of abstraction.

> This code makes use of these multipath convensions.
> 
> 
> > this is for multipath. I found that there was a currently-unused function in
> > multipath.py that does most of what we want so I changed it to return the
> > partition number as well and changed this code. (it used udev rather than
> > sysfs pokery but well. no real difference).
> 
> OK, sounds good!  I'll review.
> 
> > On the subject of mocks, get_blockdev_for_partition is currently untested.
> > Tests could be written but you'd have to mock so many filesystem accesses
> that
> > it would be incredibly fragile and I'm not sure what value it would bring.
> >
> > You must have thought about a more generic way to mock the filesystem by
> now,
> > surely, like something where you supply a dictionary mapping paths to
> > content and mocks for the various os.path.* functions get set up for you?
> > Did you ever write anything for this I can steal? :)
> 
> 
> I think the closes thing we have is using tests/unittests/helpers.py:dir2dict
> and populate_dir and FilesystemMocking unittest class'[1] reRoot() method
> which
> effectively applies a chroot prefix to the operations.

Yeah, that's the sort of thing I was thinking of, although I guess I was more imagining something in memory (which would be more effort to implement but presumably faster in execution).

> 1. https://github.com/canonical/cloud-
> init/blob/master/cloudinit/tests/helpers.py#L242
-- 
https://code.launchpad.net/~mwhudson/curtin/+git/curtin/+merge/396462
Your team curtin developers is requested to review the proposed merge of ~mwhudson/curtin:fix-multipath-partition-verification-2 into curtin:master.