Ticket #159 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Network Device Naming Test Day

Reported by: shyamiyerdell Owned by: narendra_k@…
Priority: major Milestone: Fedora 15
Component: Test Day Version:
Keywords: Cc: matt_domsch@…, shyam_iyer@…, charles_rose@…, jordan_hargrave@…, adamwill, paniraja_km@…
Blocked By: Blocking:

Description

This test day is to ensure that we have a sane solution to the NIC Naming problem described here http://linux.dell.com/files/presentations/Linux_Plumbers_Conf_2010/matt-domsch-network-device-naming.pdf This is being solved in biosdevname, udev and the installer. http://www.spinics.net/lists/fedora-devel/msg147124.html

Testcases to come.

Attachments

Example Onboard and PCI Add-in network adapter ports.jpg (38.2 KB) - added by narendrak 3 years ago.
Example picture of Onboard and PCI Add-in network adapter ports
Onboard Network Adapter Ports.jpg (83.1 KB) - added by narendrak 3 years ago.
Example picture of Onboard Network Adapter ports showing server chassis labels such as Gb1 and Gb2

Change History

comment:1 follow-up: ↓ 2 Changed 3 years ago by adamwill

  • Cc adamwill added

awesome! yell if you need any help. just to make sure - you're aware of the test day SOP, right? it'll help you in setting up a test day:

https://fedoraproject.org/wiki/QA/SOP_Test_Day_management

comment:2 in reply to: ↑ 1 Changed 3 years ago by shyamiyerdell

Replying to adamwill:

awesome! yell if you need any help. just to make sure - you're aware of the test day SOP, right? it'll help you in setting up a test day:

https://fedoraproject.org/wiki/QA/SOP_Test_Day_management

Thanks! What is the process to reserve the time/day slot. Should I just go ahead and edit the wiki to claim the time slot ?

comment:4 Changed 3 years ago by adamwill

yup: it's first come, first served :) go ahead and grab the slot you want. do consider where in the release cycle it'd make most sense: usually as early as possible after you expect to have all the code done and ready is best, as it gives you the most time to fix any issues that arise.

i'd imagine you'll be able to do most of the testing for this from a nightly live image? http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ . it's always good when that's the case, as it makes it much easier for people to get involved and test.

comment:5 Changed 3 years ago by jlaska

shyamiyerdell: we are almost two weeks away from the schedule event date. I wanted to reach out and see if you had any questions, or needed help preparing the wiki pages, or building test images etc...

comment:6 Changed 3 years ago by narendrak

Hi, I have created a wiki page and in the process of updating it.

https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Naming_With_Biosdevname

comment:7 Changed 3 years ago by narendrak

  • Cc paniraja_km@… added

comment:8 Changed 3 years ago by narendrak

It would be great to know if there are any suggestions/feedback on the wiki page. I have a couple of sections not updated as of now.(Installation section and Test Results).

Any suggestions on the 'Test Results' section would be great to make it effective.

comment:9 Changed 3 years ago by adamwill

Hey Narendra! Thanks for all the work on this.

Here's my suggestions:

It would be good to compress the stuff at the top a bit, maybe leave out some of it that's mentioned in the pages that are linked to. Too much explanation can be a bit overwhelming. I'd also recommend putting, very near the top, some very simple instructions on how to find out if you have the necessary hardware. As simple as possible is best. For instance, for the X test days, we provide a little command you can run:

/sbin/lspci -d 10de: | grep -iq VGA && echo "Join Nouveau Fedora Test Day"
echo "No nVidia graphics hardware found."

which gives you a nice easy 'yes/no' answer :) something like that would be great.

The 'test results' table should usually just have each separate test case as a column, and each tester as a row, so you have at a glance each tester's result for each test case. If you need to capture more data than that, let us know what, and we can come up with some ideas.

If all the testing can be done from a live image it's often a good idea to emphasize the live image path strongly in the 'how to test' and 'prerequisites' section, as for most people it's a lot easier to just boot a live image than set up an installed rawhide system. As I mentioned in a previous comment, you can link to a nightly rawhide image from http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ for people to use, as long as all the stuff that needs testing is in Rawhide already. If not, we can do a custom test day live build.

comment:10 Changed 3 years ago by jlaska

In addition to Adam's suggestions, I think I'd also suggest ...

  1. renaming your proposed test cases to avoid name collisions. Some of the testes are somewhat generic and may collide with other similarly named tests. Ideally, prefixing each test with an package name (e.g. biosdevname) can help. For example, you could prefix each test with "QA:Testcase_biosdevname_" to guarantee no collisions. Alternatively, I provided some suggested names below, please let me know what you would prefer.
Current Proposed name
QA:Testcase_Upgrade QA:Testcase_NIC_rules_persist_on_upgrade
QA:Testcase_Onboard_Network_Interface_Namesnamed_as_emN good
QA:Testcase_PCI_Add-In-Network-Interace_Names good
QA:Testcase_SRIOV_Virtual_Function_Interface_Names good
QA:Testcase_Interface_Configuration QA:Testcase_biosdevname_iface_config
QA:Testcase_Install_Time_Network_Interface_Names good
  1. To ensure test cases continue to have a standard look'n'feel, I recommend using Template:QA/Test_Case. For additional details on creating/editing tests, see https://fedoraproject.org/wiki/QA:SOP_test_case_creation.
  2. I recommend categorizing your tests for easy discovery at a future date. Should we organize all your tests under Category:Package_biosdevname_test_cases? For additional details on organizing your tests see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation.

I'll be happy to rename the tests, organizing them appropriately and correct them to use the test case template. Please advise on proper names, and I'll proceed.

comment:11 Changed 3 years ago by narendrak

Hi Adam,

Thanks for the suggestions. I have removed some of the details in the description section which are in test cases.

I am thinking on how to provide simple script to find out if the necessary hardware exists, but do not have anything in mind, as the Network hardware can vary. I am thinking about it.

Hi James,

Please go ahead and do the necessary renames. Prefixing biosdevname wherever required sounds good to me.

Also, i have done some categorization of test cases and will do some more tomorrow. Feel free to make changes if necessary.

comment:12 Changed 3 years ago by narendrak

James,

Just one thing to note though. I have referred to the "Run Time" test cases in "Install Time" test case. We might have to make necessary changes there too.

Changed 3 years ago by narendrak

Example picture of Onboard and PCI Add-in network adapter ports

Changed 3 years ago by narendrak

Example picture of Onboard Network Adapter ports showing server chassis labels such as Gb1 and Gb2

comment:13 Changed 3 years ago by narendrak

James,

I have two images attached two pictures, which I think would help users to identify/understand what we mean when we refer to the jargon 'onboard' and Add-in PCI ports. Looks like I need to have these images on fedoraproject.org before they can be embedded into the wiki page. Request you to put these two images on to the "What to Test Section".

comment:14 Changed 3 years ago by adamwill

I believe there's an 'upload file' link in the action bar on the left-hand side of the Wiki which lets you upload files, including (small!) images.

comment:15 Changed 3 years ago by narendrak

Thanks Adam, i will explore it.

I booted into the Rawhide Live Image - http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20110117.16.iso. It failed to show the desktop after doing an autologin. The desktop screen flickers continuously without completing autologin.

But i could switch to the text terminal and could see biosdevname, system-config-network-tui and ethtool available.

comment:16 Changed 3 years ago by jlaska

I have made the desired changes, including:

  1. Renamed all the testcases so they are prefixed with QA:Testcase_biosdevname
  2. Corrected any pages that linked to the previous test case names
  3. Updated all tests to use the Template:QA/Test_Case template
  4. Added all tests to Category:Package_biosdevname_test_cases

Feel free to upload the attached images to the wiki, and link to them in the description of applicable tests for reference. For help on linking to images, see https://fedoraproject.org/wiki/Help:Wiki_syntax_and_markup#Links

Regarding bug#670795, I have contacted the developer who is aware of the issue and will attempt to diagnose and correct the problem soon. Worst case, we can document a workaround for the problem on the wiki.

comment:17 Changed 3 years ago by adamwill

are any of the test cases critpath? i.e., if they were to fail, would networking fail to work on affected machines?

comment:18 Changed 3 years ago by adamwill

"It failed to show the desktop after doing an autologin. The desktop screen flickers continuously without completing autologin. "

gdm is crashing in a loop - https://bugzilla.redhat.com/show_bug.cgi?id=670361

I hope that'll get fixed by the test day date :)

comment:19 follow-up: ↓ 20 Changed 3 years ago by narendrak

Hi,

We are testing the installation scenario just to make sure we have everything needed in place for the test cases to succeed. To be specific, we were testing

"install Fedora Rawhide using Fedora 14 ISO media -- for guidance, see Install rawhide using Fedora 14 ISO"

With this method, during install time, when the network drivers load (from initrd), biosdevname binary and related 71-netdevice.rules required for rename is not available. Because of this we cannot test any install time scenarios.

I think we will have to fall back on to custome built Rawhide Installation images (boot.iso or DVD.iso )incorporating biosdevname binary and related udev rule as suugested by James in one of the earlier threads.

comment:20 in reply to: ↑ 19 Changed 3 years ago by jlaska

Replying to narendrak:

I think we will have to fall back on to custome built Rawhide Installation images (boot.iso or DVD.iso )incorporating biosdevname binary and related udev rule as suugested by James in one of the earlier threads.

Hi narendrak, I replied to you privately in email as well on this topic. I'll be glad to build and provide a Rawhide boot.iso for installation. However, will the required 71-netdevice.rules rules file be available during a Rawhide live image install? Will that satisfy your test requirements?

comment:21 Changed 3 years ago by jlaska

I have created a i386 and x86_64 boot.iso images and updated the test day wiki with links. Note, after install there is a traceback (see bug#672603). I'm looking into getting more information to help resolve that bug. If that bug is resolved, I'll respin the images. Otherwise, we may have an updates.img to use.

comment:22 Changed 3 years ago by narendrak

Thanks James.

comment:23 follow-up: ↓ 24 Changed 3 years ago by adamwill

I just did some clean-up, re-organization and stuff on the wiki page; hope I didn't break anything.

One thing that should be clarified...

"Single and multiport add-in network adapters with SRIOV capability"

is this something extra to test, but which still requires the BIOS capabilities mentioned? is it something extra to test, which you can test whether the BIOS is compatible or not? Or is it something you need to do any testing at all? It's not terribly clear. thanks!

comment:24 in reply to: ↑ 23 Changed 3 years ago by narendrak

Replying to adamwill:

I just did some clean-up, re-organization and stuff on the wiki page; hope I didn't break anything.

One thing that should be clarified...

"Single and multiport add-in network adapters with SRIOV capability"

is this something extra to test, but which still requires the BIOS capabilities mentioned? is it something extra to test, which you can test whether the BIOS is compatible or not? Or is it something you need to do any testing at all? It's not terribly clear. thanks!

Thanks Adam for pointing that out. I have mentioned the requisites from the BIOS side. Steps on how to enable the virtual functions itself is explained in the test case setup itself. Let me know if you think any other detail is required.

comment:25 Changed 3 years ago by narendrak

I have also modified the 'Testcase_biosdevname_SRIOV_virtual_function_interface_names' to suit it to the LiveImage? scenario.

comment:26 follow-up: ↓ 27 Changed 3 years ago by narendrak

James,

I just booted from the boot.iso you have posted.

  • I observed that the commands 'lspci', 'ifconfig' and 'ethtool' were not available early, just about when the shell came up (cotrol+alt+F2) and users might need them to execute couple of test cases. If possible (if the boot.iso will be rebuilt for tomorrow), please include the same.
  • As you noted, i saw the exception thrown, at the end. Though install did not complete, i saw the emN names in the shell prompt.

Also, i verified that the linux-firmware issue is fixes in 20110125 LiveImage?.

comment:27 in reply to: ↑ 26 Changed 3 years ago by jlaska

Replying to narendrak:

  • I observed that the commands 'lspci', 'ifconfig' and 'ethtool' were not available early, just about when the shell came up (cotrol+alt+F2) and users might need them to execute couple of test cases. If possible (if the boot.iso will be rebuilt for tomorrow), please include the same.

During stage#1, at the text language selection prompt, I pressed <ctrl>-z to get a shell. From there, the commands ifconfig, lspci and ethtool are available (see screenshot.png).

After the graphical installation starts, if I change to tty2 (<ctrl><alt>F2), I see that the same commands are available, but the PATH does not include /sbin/. I'm not sure if that's an installer bug or not. For the test day, as long as you reference the commands with the absolute path, you should be good.

  • As you noted, i saw the exception thrown, at the end. Though install did not complete, i saw the emN names in the shell prompt.

The anaconda team is investigating. A patch is available, so we'll likely have updated boot.iso's, or an updates.img to resolve that issue.

comment:28 Changed 3 years ago by adamwill

the confusion around lspci and ifconfig may be because they live in /sbin : if you log in as a regular user they will not be in the path, but you can run them as '/sbin/lspci' and '/sbin/ifconfig' .

comment:29 Changed 3 years ago by shyamiyerdell

The hardware requirement script requires that the dmidecode package be installed on the box else the script fails to detect a testable box.

I have updated the wiki to that effect

comment:30 Changed 3 years ago by jlaska

  • Status changed from new to closed
  • Resolution set to fixed

Completed, closing ticket.

Note: See TracTickets for help on using tickets.