On Mar 13, 2014, at 8:50 PM, Adam Williamson <awilliam(a)redhat.com> 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? I'd think we'd
sooner want SATA vs SAS, at least they use a different driver.
- 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.
-------------
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
Alpha QA:Testcase_partitioning_guided_delete_all
tests delete all button and ability to make a populated disk "empty"
Beta QA:Testcase_partitioning_guided_delete_partial
tests delete button, makes populated-disk have "free space"
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.
Beta QA:Testcase_partitioning_guided_multi_empty
What is this?
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).
---------
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.
- 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.
- 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? Needs a RAID column I think, if we're going to
test the anaconda supported "create raid elsewhere" and use it in anaconda
workflow.
- Seems like in general we need more RAID tests. I don't see a hardware raid test. 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?
- ext2 and ext3. I think these should be bonus, or even removed from the test matrix. Yes
they're visible in the installer (which I disagree with), therefore they should work,
and if they don't I'd consider it a blocker bug. But how many file system choices
do we need on Linux? And how many do we need to test? It's appealing to the
Smörgåsbord installer mentality which I think is in the realm of OCD please go hire a
shrink. Anything ext2/3 can do ext4 can do better and if it can't it's a bug.
Chris Murphy