Bug 589428 - Please change "Tested OS" back to be "OS Version" in output.log
Please change "Tested OS" back to be "OS Version" in output.log
Status: CLOSED CURRENTRELEASE
Product: Red Hat Hardware Certification Program
Classification: Red Hat
Component: Test Suite (tests) (Show other bugs)
5.3
All Linux
low Severity medium
: ---
: ---
Assigned To: Greg Nichols
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-06 02:23 EDT by QinXie
Modified: 2010-11-19 10:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-19 10:39:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for this bug (330 bytes, patch)
2010-05-12 01:19 EDT, Mao DengFeng
no flags Details | Diff

  None (edit)
Description QinXie 2010-05-06 02:23:38 EDT
Following is copied from https://hardware.redhat.com/show.cgi?id=574730#c40
<snip>
Created
an attachment (id=411328)
v7-Intel_Corporation-S5520HC-Tikanga_x86_64_results-20100504100128.noarch.rpm


OS Version: Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Kernel Version: kernel-xen-2.6.18-164.el5
</snip>

I checked the /etc/redhat-release, it's RHEL5.4
<snip>
[cqin@localhost 176123_sysreport]$ cat etc/redhat-release 
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
[cqin@localhost 176123_sysreport]$ 
</snip>

Don't know why catalog reported it as RHEL5.3, what ever, it's wrong. Can we have a catalog update to fix this?
Comment 1 Mao DengFeng 2010-05-10 06:15:37 EDT
I have checked the codes. The string 'OS Version: Red Hat Enterprise Linux Server release 5.3 (Tikanga)' actually comes from output.log.
I can't find 'redhat-release' file from the package. 
Where did you get the file?
Comment 2 QinXie 2010-05-10 22:08:13 EDT
uhm, looks it's from the fv_test(run #2,#3,#4 or #5) running on domU. I remember catalog used to get this value from the first run, but not the subsequent runs.  side effect of last catalog udate?

you can get redhat-release from the tar ball, which locates in the same directory of output.log. 
eg: /home/cqin/Review/574730/411328_cpio/log/v7/v7-Intel_Corporation-S5520HC-Tikanga_x86_64_results/var/log/v7/runs/2/INFO
Comment 3 Mao DengFeng 2010-05-10 22:25:54 EDT
I checked the latest update for this file. It has nothing to do with this. From the codes. the 'OS Version' is extracted from the output.log of the last run instead of the first run.
Comment 4 QinXie 2010-05-11 01:59:23 EDT
Which run does this line come from:
Kernel Version: kernel-xen-2.6.18-164.el5

If it's not from the last run, it is strange to show kernel version from to different source. 

Thanks
QinXie
Comment 5 Mao DengFeng 2010-05-11 02:09:35 EDT
It's also from the last run of output.log
Comment 6 QinXie 2010-05-11 02:19:39 EDT
(In reply to comment #5)
> It's also from the last run of output.log    

I think you made a mistake. The last run is based on rhel5.3, it's impossible to find the clue of RHEL5.4.
<snip>
Running ./info.py:
OS Version: Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Kernel RPM: kernel-2.6.18-128.el5
v7 version 1.0, release 15
+ rpm -ql kernel-2.6.18-128.el5
</snip>

And please take a look attachment id=389004,  https://hardware.redhat.com/show.cgi?id=562071#c2, which is an example of the old catalog. Looks the kernel version and OS version are from the 1st run. Conflict with what you said, from the last run.
Comment 7 Mao DengFeng 2010-05-11 02:53:29 EDT
  oh...It's my fault. I see the part of getting os version and kernel version in the run loop from 0 to 500. So I has thought they were come from the last run. Acutally, there is a condition, if both os version and kernel version have gotten some value, they will not be evaluated again.
  
I think that's the point, the condition is just both of them have some value.but not restrict the value come from the the same output.log file. There is a case like OS Version but no kernel version exist in test run 0 and kernel version but no OS Version exist in test run 1. In this case, OS version will come from test run 0 and kernel version will come from test run 1. After that, both of them have value,they will not be evaluated again.

  Below is the codes for OS version and kernel version

     .... ...
       if ($type eq 'INFO') {
                # Find the kernel version and OS vesrion from the output.log file
                foreach my $line (@rundata) {
                    if ($kernelver && $osversion) {
                        last;
                    }
                    if ($line =~ /\+ rpm -ql (.*)/) {
                        $kernelver = $1;
                    }
                    if ($line =~ /OS Version: (.*)/) {
                        $osversion= $1;
                    }
                }
            }

    ...  ...
Comment 8 QinXie 2010-05-11 03:19:09 EDT
Mao,
Thanks for your explanation.

Greg,
In v7-1.1-23,  "OS Version" is replaced by "Tested OS", but catalog sorting it by keyword "OS Version". Can you change it back to "OS Version".
Comment 9 QinXie 2010-05-11 23:27:11 EDT
Below is che codes for OS version in v7-1.1-23 release:
filename: info.py
<snip>
class InfoTest(Test):

    def __init__(self):
    ......
    ......
        print "Tested OS: %s %s (%s)" % (self.redHatRelease.getProduct(), self.redHatRelease.getVersion(), self.redHatRelease.getCodeName())
    ......
</snip>
Comment 10 Mao DengFeng 2010-05-12 01:19:52 EDT
Created attachment 413326 [details]
patch for this bug
Comment 11 QinXie 2010-05-12 04:10:19 EDT
(In reply to comment #10)
> Created an attachment (id=413326) [details]
> patch for this bug    

I have tested with this patch. Old version and new version both work with it.
Comment 17 Rob Landry 2010-11-18 14:31:20 EST
Can this bug be closed out?
Comment 18 QinXie 2010-11-19 02:05:13 EST
yes, please.

Note You need to log in before you can comment on or make changes to this bug.