Description of problem:

In a RHEV 3.1 environment, the vdsm release being used on a RHEV host is (currently) 4.9.6. The release is reported in the 'vdsm.log' as "I am the actual vdsm 4.9-x.x", as opposed to "I am the actual vdsm 4.9.6-x.x".

This is somewhat trivial. In the RHEV-M GUI the vdsm release is identified as "vdsm-4.9.6-44.1.el6_3", so there is a way of quickly determining the version of vdsm. However, when troubleshooting a customer's problem remotely, if you only have specific log files, then a quick way of determining the vdsm release is by analysing the "I am the actual vdsm" line. Also, when a LogCollector is captured, this apparently doesn't have an rpm listing included for each host. It does however contain a YUM log, which would hopefullu contain the rpm version for vdsm. So, there are ways of determining the correct release of vdsm, other than relying on the vdsm log itself. However, seeing as the vdsm log is most likely going to be one of the first places to look for a RHEV host problem, then having the correct release/version information in it would facilitate troubleshooting. As I said, this is trivial, but if it's simple to address (see 'Additional info' below) then why not fix it.


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

RHEV 3.1
VDSM 4.9.6


How reproducible:

When the vdsm service is restarted the message "I am the actual vdsm" is written to the 'vdsm.log' file.


Steps to Reproduce:

1. Start vdsm service on a RHEV host.
2. Look at the 'vdsm.log'.

  
Actual results:

$ rpm -q vdsm
vdsm-4.9.6-44.1.el6_3.x86_64

$ grep software /usr/share/vdsm/dsaversion.py |grep '='
software_version = "4.9"
software_revision = "44.1"

$ grep 'I am' /var/log/vdsm/vdsm.log
:MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9-44.1


Expected results:

:MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9.6-44.1


Additional info:

The 'vdsm.spec.in' file contains the following lines;

# Setting software_version and software_revision in dsaversion.py
baserelease=`echo "%{release}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'`
baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'`
sed -i -e 's/^software_version =.*/software_version = "'"${baseversion}"'"/' \
       -e 's/^software_revision =.*/software_revision = "'"${baserelease}"'"/' vdsm/dsaversion.py


The 'vdsm/dsaversion.py.in' file contains;

software_version = "@PACKAGE_VERSION@"
software_revision = "@PACKAGE_RELEASE@"


If the 'baseversion' line in the 'vdsm.spec.in' file above is changed to;

  baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\0/'`

then the following lines get generated in '/usr/share/vdsm/dsaversion.py';

  software_version = "4.9.6"
  software_revision = "44.1"

which in turn would result in 'vdsm' reporting "I am the actual vdsm 4.9.6-44.1" on a subsequent restart.

However, that seems too easy. Is there some case where this wouldn't work ???  Just me second-guessing myself.