Adam Williamson said it best, anaconda storage testing is a tough thing to get folks excited about. It doesn’t rotate on a cube, slowly spew solar flares or read your fingerprint … but it sets the stage for everything that comes after you first boot up a Fedora 11 install. Naturally, getting things right is important … and failing during installation is a quick way to ward off potential contributors.
It’s an understatement to say the weeks leading up to the test day were very busy for the anaconda development team. To reduce the disruption to rawhide users, the storage rewrite changes were self-contained in a rather large updates.img. Which is something considering "all of anaconda’s code for creating and configuring disk partitions, LVM, mdraid, dmraid, multipath, iSCSI, LUKS devices, and filesystems is being rewritten." 
The day began by emphasizing the raw in rawhide. Mirrors were still updating which caused confusion while testing patches and raised the question … what rawhide am I testing? What seemed to help here was:
- Patience – the mirrors eventually had the latest and greatest content … but there’s no GREEN light that tells you a mirror is up to date
- .treeinfo – this file in the base directory of any installation tree contains a SHA256 hash for every file included in the tree. Comparing it’s contents with the main download site can be helpful.
With that behind us the rubber met the road. The focus for the day was excercising the most common use cases to reduce the number of obvious warts when the changes hit rawhide. This includes, but not limited to, most every operation you can perform from the disk partitioning step seen below.
At the time of this post, testing that fell in the category of "things not expected to work" included:
- partitioning via kickstart
- discovery of existing mdraid arrays
- user interaction through anaconda screens (clicking Next/Back)
- hardware raid controllers that have nonstandard device paths, like cciss (untested, not expected to work)
- resizing of devices/filesystems
- bootloader setup on multi-boot systems (untested)
The event was very busy and only possible thanks to the hard work of folks like Dave Lehman, Chris Lumens, and Joel Granados. Throughout the day they were able to traige, patch, review and integrate hotfixes into an updates.img for testers. Also many thanks to testers for coming armed with interesting storage environments (j-rod and refried).
While not everything was filed in bugzilla, the list of formerly recorded issues found includes:
|488722||Properly align encrypted LV – LUKS device|
|488743||ImportError: No module named partRequests|
|488747||NameError: global name ‘iutil’ is not defined|
|488772||[StorageRewrite] Traceback during kickstart install|
|488800||[StorageRewrite] DeviceException: Could not find device for path /dev/sdb|
|488807||[StorageRewrite] PartitionException: no type specified|
|488812||[StorageRewrite] TypeError: ‘NoDevice’ object is not iterable|
|488859||[StorageRewrite] TypeError: argument 2 must be string, not None|
|488860||[StorageRewrite] Adding iSCSI device fails – TypeError: ‘Storage’ object is not iterable|
|488861||[StorageRewrite] LVMError: pvremove failed for /dev/sda1 – custom partitioning with 1 local and 1 iSCSI disk fails|
At the end of the test day, several things were very clear:
- We need more interesting storage environments to throw at anaconda (SAN’s, FC, multiple disks, dmraid, mdraid, iSCSI)
- We need to provide another collaborative forum for testing #1
- I heart virt-manager and kvm