> > 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. -- Mailing list: https://launchpad.net/~curtin-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~curtin-dev More help : https://help.launchpad.net/ListHelp
