Bug 684075

Summary: the hardware <make/> tag in results.xml is never set.
Product: [Retired] Red Hat Hardware Certification Program Reporter: Wei Shen <wshen>
Component: Test Suite (harness)Assignee: Greg Nichols <gnichols>
Status: CLOSED ERRATA QA Contact: Guangze Bai <gbai>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.2CC: czhang, gbai, junwang, rlandry, yshao
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
in v7 1.4, an enhancement has been made that on first run v7 will prompt user to verify vendor, make and model and allow user to edit the default values. These values will be stored in results.xml
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-08 15:41:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
the sample rpm
none
hardware test patch adding verification prompts for vendor, make and model
none
patch for new promptEdit method to support editing default values none

Description Wei Shen 2011-03-11 02:27:52 UTC
Created attachment 483626 [details]
the sample rpm

Description of problem:
The 'make' in results.xml is null

Version-Release number of selected component (if applicable):

1.2.25
How reproducible:


Steps to Reproduce:
1. download an rpm produced by v7 1.2.25,extract it and look at the make tag
2.
3.
  
Actual results:
it is null

Expected results:
there is a make

Additional info:

Comment 1 Greg Nichols 2011-03-11 11:54:58 UTC
What should it be set to?   v7 currently does not set "make" to anything.

We use dmidecode to set "vendor" and "model", failing that, we check /proc/device-tree/model, or use arch for some IBM systems' vendor.

If none of that works, v7 will prompt the user for vendor and model.

Comment 2 Rob Landry 2011-06-21 16:42:52 UTC
Looks like we can use the 2nd word in product name; where the 3rd is model.  1st seems to be a version of vendor.

Product Name: HP EliteBook 8560w
Product Name: Lenovo ThinkServer TS430

(I'm not certain how representative the above two random examples are.)

Instead of presuming v7/dmidecode got it right with the only option being to hand edit results.xml when it isn't could v7 prompt the user providing a default of what it finds this way the user could confirm/correct the values?

Comment 3 Greg Nichols 2011-07-07 17:29:33 UTC
Created attachment 511761 [details]
hardware test patch adding verification prompts for vendor, make and model

Comment 4 Greg Nichols 2011-07-07 17:30:35 UTC
Created attachment 511762 [details]
patch for new promptEdit method to support editing default values

Comment 5 Greg Nichols 2011-07-07 17:33:07 UTC
Example log of the above patches:

[root@blueshirt v7]# v7 plan
Please verify the vendor, make, and model:
Vendor: LENOVO
Make: Thinkpad
Model: T500 2241B36
Hardware: LENOVO Thinkpad T500 2241B36

In this example, the field defaults were:

Vendor: LENOVO
Make: 
Model: 2241B36

Comment 9 Caspar Zhang 2011-10-21 14:15:31 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
in v7 1.4, an enhancement has been made that on first run v7 will prompt user to verify vendor, make and model and allow user to edit the default values. These values will be stored in results.xml

Comment 10 errata-xmlrpc 2011-11-08 15:41:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1436.html

Comment 11 errata-xmlrpc 2011-11-08 18:30:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1436.html