Need a resource job to detect /dev/mapper devices

[Jeff Lane ]

Need a new resource job and script to detect the presence of /dev/mapper devices.

This will allow for easy testing with checkbox standard storage tests against things like multi-pathed internal storage, software RAID, LVM, and anything else that creates devices within /dev/mapper.

This is critical right now for doing Power8 certification as the current crop of P8 machines are configured with on-board multipath RAID, e.g. two RAID cards using multipathing to connect to the same on-board disks to provide redundant pathways.

We are NOT, at this time, planning on testing the failover/failback features of multipathing, but we are unable to test at all via checkbox as it only looks for actual block devices.

On a system with multipathing enabled, the kernel sees two block devs for each physical device, e.g. a look at udev would show both an sda and sdg with the same UUID and physical address, thus the same physical device but presented as two separate devices.

the fix to include multipath tools in Ubuntu now properly provides a /dev/mapper/mpathX device for each multipath array, similar to how LVM devices appear in /dev/mapper as well.

A generic resource to look at /dev/mapper would be great to help test all manner of mapped devices.

Suggestion, it should provide a resource like this:

devmapper.lvm = true|false
devmapper.mpath = true|false

etc.

The corresponding bug to this is: https://bugs.launchpad.net/plainbox-provider-checkbox/+bug/1467520
which is for writing actual tests for these devices.

[Jeff Lane  (bladernr)]

Discussion elsewhere has indicated that this is not quite cut and dried, but to be honest, I'm not entirely sure why. Can someone explain why this is difficult to implement? What I had in mind was essentially somethign like above that simply returns a true or false, or just a true if a dev/mapper device exists.

Then jobs could do something like this:

name: storage-a-palooza
requires:
  devmapper.mpath = false
  blockdev.removable = false

and

name: multi-path-storage-o-rama
requires:
 devmapper.mpath = true

[Jeff Lane  (bladernr)]

This hasn't been updated yet, but this is going to be a bigger issue soon. MAAS 1.9 defaults to an LVM arrangement for deployments which will also cause the storage tests to fail as LVM uses dev/mapper as well.

So this issue will extend beyond the limited use case of multipath.

[Jeff Lane  (bladernr)]

Hey Sylvain,

I need some help with running your changes... here's what I did:

Installed a system with multipath disks.
installed CCS from the stable PPA
cloned your branch
./setup.py build
sudo ./setup.py install
then ran CCS with the Storage Only list.

It then attempted to generate the jobs and dumped a traceback:
http://pastebin.ubuntu.com/24086650/

So maybe installing that way caused me to miss some component, I'm not sure. Could you take a peek and let me know if there is something different I need to do?

Thanks
Jeff