Fedora QA Meeting -- no meeting scheduled

[James Laska]

On Tue, 2009-12-22 at 09:04 -0600, Adam Miller wrote:
> On Mon, Dec 21, 2009 at 7:42 AM, James Laska <jlaska at redhat.com> wrote:
> <SNIP>
> >        5. adamw and jlaska to look at setting up f13 test day process
> >
> >              * Initial ideas posted to
> >                https://fedoraproject.org/wiki/Talk:QA/Fedora_13_test_days
> >              * Includes ...
> >                      * Anaconda storage UI changes (SAN changes)
> >                      * libcurl/proxy support
> >                      * mdadm/dmraid completion
> >                      * preupgrade
> >                      * Features/SystemPythonExecutablesUseSystemPython
> >                        - may impact breaking python applications when
> >                        the python3 change happens?
> >                      * Rehash of gnome-disk-utility changes
> >                      * Features/SSSDByDefault
> >                      * Features/NouveauDisplayPort
> >                      * Features/RadeonDisplayPort
> >
> 
> Just wanted to jump in here and start up a conversation based on this
> bit, mainly in respect to the SAN features of Anaconda. While a
> welcome change, I don't necessarily know that a large enough portion
> of the user base is going to have the necessary hardware to really
> test this so I was wondering what would be considered as a sufficient
> test of these features by Anaconda standards and if we could offer up
> some docs in the wiki for the test day on how to create a "scratch
> file" (I've heard it called a multitude of things, but that seems to
> be common verbage) such that it can be exported over iSCSI and offer
> that functionality. 

I've not heard of the scratch file solution, that might be something to
consider.  I'm fairly comfortable with iSCSI, which is surprisingly not
difficult to setup for testing
(https://fedoraproject.org/wiki/Scsi-target-utils_Quickstart_Guide).  If
there are other 'do-it-yourself' solutions that don't require hardware,
they might be worth exploring.

> We have a couple FibreChannel SANs here at the
> office but I can't promise I can con my boss into letting me use one
> of them for Fedora testing ;)
> I know hardware is always a concern, but I just think "enterprise
> class" storage solutions will be even more rare. Just a thought I
> wanted to toss out there for discussion.

Thanks for raising Adam.

Hardware is definitely a factor whenever we host install-based test
events.  For example, the RAID test event wasn't able to draw out the
hardware raid (or BIOS raid) we had hoped for.  I gather that part of
the problem is people don't realize whether the hardware on the system
supports RAID.  If they do, it's probably in production because it's
expensive.  It also might be their only system, so it might be a bit
daunting to mess with on your *only* production system.  

In some way, I wish we had more virt-based solutions that would allow
testers to mimic a true hardware setup (RAID, SANs, FCoE, iSCSI iBFT
etc...).  While this wouldn't let us explore edge conditions with
specific hardware setups, it might at least shake out the obvious
interaction issues.  

Alternatively, are there pockets of interest out there who have
specialty hardware and would be interested in coming together to
identify and resolve issues in Fedora?

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20091222/b2922d2e/attachment.sig>