Re: Very rough storage validation matrix draft

[Chris Murphy]

On Mar 17, 2014, at 1:33 PM, Adam Williamson  wrote:
> 
> 
>> 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.)

Patch. Testcase_partitioning_guided_multi_empty > 
Testcase_partitioning_guided_multidev_empty

Basically, pick two devices and see if anything blows up during install or 
first boot.


>> - 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.

We can make that a bonus column *shrug* it's not obviously supported in the 
installer but the anaconda team has said it's supposed to work.


> 
>> - 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.

Mmm, well I'm not sure what the failure vectors are for HW and BIOS RAID. The 
hwraid case should just look and behave like an ordinary single device. The 
firmware RAID case starts out the same way at boot time, but then becomes a 
variation of software raid, as it's implemented by mdadm, the only difference 
being on-disk metadata format.

Looks like in Rawhide's installer Firmware RAID is listed in specialized disks, 
which is different than hardware raid I think.

Anyway, I see why they're tested separately.

> 
>> 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.

I think any raid layout is a small population of the user base. But I also 
think there's broad benefit to resiliently bootable raid1, so it makes sense 
for us to care about /boot, rootfs, and /home on raid1, and hopefully refine it 
so that one day it'll work better on UEFI than it does now. And then expand 
scope as resources permit.

Everything else I think is totally esoteric. Ideology wise, I think since it's 
offered in the installer it ought to work. But I also don't want to test 
esoteric stuff when basic, broadly useful stuff, needs attention. I think the 
iSCSI/SAN stuff is way more useful than enabling installation time creation of 
or install to software raid other than level 1.

Anyone know if we can boot off a glusterfs volume? Random question…

I'm not going to be much use for anything but occasional emails, taking pot 
shots, etc. for the next 3-4 weeks: crashed into a tree while skiing Friday, 
have a week to prepare 3 presentations for Libre Graphics Meeting, a wedding, 
travel to/fr Germany for LGM. Plus recovery. And mostly I'm emailing now 
because I'm procrastinating.



Chris Murphy

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Adam Williamson]

On Mon, 2014-03-17 at 12:47 -0600, Chris Murphy wrote:
> On Mar 13, 2014, at 8:50 PM, Adam Williamson  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

Re: Very rough storage validation matrix draft

[Chris Murphy]

On Mar 17, 2014, at 1:12 PM, Al Dunsmuir  wrote:

> On Monday, March 17, 2014, 2:47:56 PM, Chris Murphy wrote:
>> On Mar 13, 2014, at 8:50 PM, Adam Williamson  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.
> 
> On ARM the majority will be MMC, with some SATA that may involve USB.
> On PPC (secondary arch) SCSI is still quite important.

Right so does it make sense to have these as separate categories:

SATA/PATA
SCSI/SAS
MMC/SDCard
USB
PCIe SSD (which may morph into NVMe)

?

I guess I'm not seeing the point of separate PATA/SATA device tests is my main 
point, and second is that there are other devices not in the list that maybe 
ought to be in the list.

Chris Murphy

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Al Dunsmuir]

On Monday, March 17, 2014, 2:47:56 PM, Chris Murphy wrote:
> On Mar 13, 2014, at 8:50 PM, Adam Williamson  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.

On ARM the majority will be MMC, with some SATA that may involve USB.
On PPC (secondary arch) SCSI is still quite important.




-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Al Dunsmuir]

On Monday, March 17, 2014, 12:13:38 PM, Adam Williamson wrote:
> On Mon, 2014-03-17 at 10:25 -0400, Al Dunsmuir wrote:
>> On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote:
>> > I can't either, and even if I did, I don't think it would justify
>> > the result number explosion. Storage is storage, arch is usually 
>> > completely irrelevant.
>> 
>> > When we're at it, why do we have both i686 and x86_64 at "Device
>> > tests"? A single results column for x86 should be enough. Same reasoning.
>> 
>> In  the  past, some filesystems have had issues handling 64-bit inodes
>> in  32-bit  architectures.  User  data  is  too  important  to make an
>> assumption that these no longer will occur.

> Device tests are not filesystem tests, though.

> Could you provide some references to these issues?

XFS  has  had  bugs  related to this which showed up with large disks
and large numbers of files.

Recent example:
  NFS + large XFS fs sometimes fails uncached lookups for client when inode 
number >2^32 on 32-bit computers
  https://bugzilla.redhat.com/show_bug.cgi?id=1003546

Application code had some problems.  For example, Adobe code (not that
we really care about closed source packages from outside Fedora).

  Bug: Adobe Reader 64-bit inode problem
  http://forums.adobe.com/message/4721987


> With either set of tests, though, I don't see that any 'user data' is
> involved: in each case the only partitions we're creating or touching
> are new ones with no user data involved. Even if one of the filesystems
> we create might suffer from a bug further down the line, I don't think
> any of these tests would catch it, would they?
> -- 
> Adam Williamson

Likely   not   a  significant  risk,  but  it  seems  useful  to me to
explicitly   identify  the  architecture that has been tested, so IF a
problem does arise in the future that information is freely available.
Al


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Chris Murphy]

On Mar 17, 2014, at 10:13 AM, Adam Williamson  wrote:

> On Mon, 2014-03-17 at 10:25 -0400, Al Dunsmuir wrote:
>> On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote:
>>> I can't either, and even if I did, I don't think it would justify
>>> the result number explosion. Storage is storage, arch is usually completely 
>>> irrelevant.
>> 
>>> When we're at it, why do we have both i686 and x86_64 at "Device
>>> tests"? A single results column for x86 should be enough. Same reasoning.
>> 
>> In  the  past, some filesystems have had issues handling 64-bit inodes
>> in  32-bit  architectures.  User  data  is  too  important  to make an
>> assumption that these no longer will occur.
> 
> Device tests are not filesystem tests, though.
> 
> Could you provide some references to these issues?
> 
> With either set of tests, though, I don't see that any 'user data' is
> involved: in each case the only partitions we're creating or touching
> are new ones with no user data involved. Even if one of the filesystems
> we create might suffer from a bug further down the line, I don't think
> any of these tests would catch it, would they?

Maybe, but I think it's a really small surface area. I've got an i686 case 
where mkfs.blah permits the creation of a > 16TB volume, but fails to mount it 
in the case of ext4 and XFS. I'm told the mount failure is correct behavior 
(jury is still out on whether Btrfs permitting this is a bug or not). But 
probably the mkfs shouldn't be allowed.

So if the installer permits 16+TB storage to be created, mkfs works, mount 
fails, installer blows up. Thing is, when I try to do this in the installer it 
sometimes permits me to create such large storage, and other times not and I 
haven't figured out a pattern so I gave up on anaconda 20, and need to redo 
this testing on 21.

And then some of the storage devs seem to think any user creating such large 
storage on memory limited i686 hardware are crazy; yet I'm thinking, this is 
made easy by cheap i686 hardware and cheap 4+TB drives. So it's crazy, but it's 
a trap!

So, maybe, I don't know.

Chris Murphy

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Chris Murphy]

On Mar 13, 2014, at 8:50 PM, Adam Williamson  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"

BetaQA:Testcase_partitioning_guided_delete_partial  
tests delete button, makes populated-disk have "free space"

BetaQA: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.

BetaQA:Testcase_partitioning_guided_multi_empty
What is this?

BetaQA: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

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Adam Williamson]

On Mon, 2014-03-17 at 10:25 -0400, Al Dunsmuir wrote:
> On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote:
> > I can't either, and even if I did, I don't think it would justify
> > the result number explosion. Storage is storage, arch is usually completely 
> > irrelevant.
> 
> > When we're at it, why do we have both i686 and x86_64 at "Device
> > tests"? A single results column for x86 should be enough. Same reasoning.
> 
> In  the  past, some filesystems have had issues handling 64-bit inodes
> in  32-bit  architectures.  User  data  is  too  important  to make an
> assumption that these no longer will occur.

Device tests are not filesystem tests, though.

Could you provide some references to these issues?

With either set of tests, though, I don't see that any 'user data' is
involved: in each case the only partitions we're creating or touching
are new ones with no user data involved. Even if one of the filesystems
we create might suffer from a bug further down the line, I don't think
any of these tests would catch it, would they?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Al Dunsmuir]

On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote:
> I can't either, and even if I did, I don't think it would justify
> the result number explosion. Storage is storage, arch is usually completely 
> irrelevant.

> When we're at it, why do we have both i686 and x86_64 at "Device
> tests"? A single results column for x86 should be enough. Same reasoning.

In  the  past, some filesystems have had issues handling 64-bit inodes
in  32-bit  architectures.  User  data  is  too  important  to make an
assumption that these no longer will occur.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Very rough storage validation matrix draft

[Kamil Paral]

> On Fri, 2014-03-14 at 04:47 -0400, Kamil Paral wrote:
> > > the result columns used to be for different filesystems. Now they're for
> > > different platforms - x86 BIOS, x86 UEFI, and ARM.
> > 
> > This is a bit unclear for me.
> > 
> > Does "x86 BIOS" mean "x86 BIOS _or_ x86_64 BIOS", and "x86 UEFI" mean
> > "x86_64 UEFI"?
> 
> I picked x86 to be "bitness-independent", the point being x86 not ARM.

x86 is unfortunately often used to refer to 32b arch only. But I see no other 
term which could be used to mean x86(_32)+x86_64, so let's leave it like that.

> We could have x32 BIOS, x64 BIOS, x64 UEFI, but I was trying to keep the
> numbers down. Have we ever found a case where storage behaved
> differently between x32 and x64? I can't recall one.

I can't either, and even if I did, I don't think it would justify the result 
number explosion. Storage is storage, arch is usually completely irrelevant.

When we're at it, why do we have both i686 and x86_64 at "Device tests"? A 
single results column for x86 should be enough. Same reasoning.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Gnome desktop not always logging in properly.

[Vasilis Keramidas]

I have the exact same problem. I had already submitted a bug with logs and
a screenshot for this. https://bugzilla.redhat.com/show_bug.cgi?id=1075465.


On Mon, Mar 17, 2014 at 7:40 AM, antonio wrote:

> Rodd Clarkson ha scritto / said the followingil giorno/on 17/03/2014
> 03:10:
>
>>
>> On 17 March 2014 12:21, Michal Jaegermann > > wrote:
>>
>> On Mon, Mar 17, 2014 at 10:22:24AM +1100, Rodd Clarkson wrote:
>>  > Applications work, but you can't log out or
>>  > restart and everything is squashed.  I'm seeing this in two
>> environments
>>  > (my laptop, and the schools computer lab).  Is anyone else having
>> issues.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1063093
>>
>> Not even acknowledged.  OTOH I do not see any squashing.  That may be
>> another bug.  Maybe something is mixed up about your screens
>> resolution?
>>
>> Michal
>>
>>
>> I've got a few bugs that haven't been acknowledged recently (read a lot).
>>
>> This bug isn't what I'm seeing.  I have however seen this problem in the
>> lab and have added to it and CCed myself.
>>
>>
>> Rodd
>>
>>
>>  added myself to the  bug, some differences but sometimes I get the
> desktop menu on the right top screen blured and in vertical position no
> poweroff button and a gear on the left bottom angle, no lens space on top
> of screen
>
> --
> Antonio M
> Skype: amontag52
>
> Linux Fedora F20 (Heisenbug) on PcDesktop1
>
> http://lugsaronno.altervista.org
> http://www.campingmonterosa.com
>
>
>
>
>
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test