On Mon, 2014-03-17 at 12:47 -0600, Chris Murphy wrote: > On Mar 13, 2014, at 8:50 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > > > > What does everyone think? Thanks! > > > Device tests: > > -PATA? They aren't made anymore, do we really need to distinguish > between SATA and PATA? Is there a case where it worked on one but not > the other? Not that I can recall, at least in the last few releases. > I'd think we'd sooner want SATA vs SAS, at least they use a different > driver. Yeah, it may be time to ditch this one. > - I'm not sure how to do a one line categorization of PCI Express > storage. But it seems like we ought to have one, for now since there > are products. And then figure out how it all relates with SATA Express > and NVMe, and whether those will need separate device tests or if > they're collapsable. Patches welcome ;) We also have SDHCI storage to consider these days, I guess, and not just on ARM: https://bugzilla.redhat.com/show_bug.cgi?id=1063556 > ------------- > > Volume type tests: Guided installation > Alpha QA:Testcase_partitioning_guided_empty > tests blank drive without partition map, should confirm whether > MBR/GPT is used in the right case Yup. > Alpha QA:Testcase_partitioning_guided_delete_all > tests delete all button and ability to make a populated disk "empty" Yup. > Beta QA:Testcase_partitioning_guided_delete_partial > tests delete button, makes populated-disk have "free space" Yup (and ensure the rest of the drive isn't touched). > Beta QA:Testcase_partitioning_guided_encrypted_empty > Does this need to be empty? Or can it be "encrypted_any"? Seems like > the target could be empty, delete_all, delete_partial, or freespace. > The code path is the same, in that it must create a partition, encrypt > it, make the dmcrypt device a PV, add it to a VG, make LVs from that. > Therefore I think the encryption outcome is tested if we do any other > test also. Yeah, that's probably right. > Beta QA:Testcase_partitioning_guided_multi_empty > What is this? More than one disk. (We *could* have multiple tests covering various scenarios here, but I was trying to keep things relatively compact.) > Beta QA:Testcase_partitioning_guided_free_space > Partially populated drive with freespace, so this is an existing > partition map with at least one entry, and also sufficient free space > for a Fedora installation (could be existing Linux, OS X, Windows, > with free space already set aside prior to arriving in anaconda). Yup. > --------- > > Custom partitioning > > - encrypted_empty_auto vs encrypted_empty_manual; doesn't seem to test > a different code path because we don't have this inheritance of the > encrypted checkbox since Installation Options dialog is vanquished. Er, you're probably right. I'd have to go back and check the context. > - What we do have a meaningful difference in custom partitioning > encryption, is that it's possible to encrypt a whole PV/VG, vs > encrypting individual LVs. And implicitly we'd want to make sure the > user can't encrypt both at the same time (a bug that I think got fixed > in F20 but was present in F19). This an LVM/LVMthinp test only though. > Nothing else permits double encryption. Good point, I'll see what can be tweaked there. > - What is QA:Testcase_partitioning_custom_existing_precreated? Layout > created elsewhere and this tests the ability of the installer to use > that without making changes? Basically assigning mount points to > existing? Yeah, I think that's what I was thinking of. > Needs a RAID column I think, if we're going to test the anaconda > supported "create raid elsewhere" and use it in anaconda workflow. Thanks. > - Seems like in general we need more RAID tests. I don't see a > hardware raid test. I can't recall whether I dropped this intentionally or inadvertently, I'll try and check. But, of course, HW raid and BIOS RAID are really rather different cases from software RAID. > Or any explicit software raid0, raid1, raid10, raid4 (a.k.a. nutcase), > raid5 or raid6 tests. Should there be a separate software raid matrix > section? And should the matrix show only what we want to > "support/test"? Or only those we'd block on? Or all possible > checkboxed options, and subjectively list some of them as "bonus" > release level, rather than alpha/beta/final? We certainly need to cover SW RAID in the custom testing, you're right, it's an obvious miss. Not sure of the best way to approach it offhand. If you'd like to draft something up that'd be great, or else I'll try and do it. > - ext2 and ext3. I think these should be bonus, or even removed from > the test matrix. Note the current draft does not explicitly specify a blocker/bonus separation, but the position we've been working towards is going back to guided being blocker and custom being bonus. But I think we probably realistically want a three-tier separation - Guided is the most important, then a small subset of Custom we really care about, then the rest of custom as very much optional-extra. But that's just not in the current draft at all; I'd agree that if we go for the three-way split ext2/ext3 would definitely be in the 'optional-extra' section. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
