Red Hat Bugzilla – Bug 985346
Share the engine's os info with DWH through a translation table
Last modified: 2016-02-10 14:15:09 EST
+++ This bug was initially created as a clone of Bug #977440 +++
Description of problem:
in 3.3 we adding the ability to add user-defined OSs to the engine.
Reports on vm os type will end with up with new entries without the actual name of the OS, as kept in the engine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
DWH keeps its own translation based on the VmOsType enum and won't have any info
on new OSs
DWH will be able to read the mapping from the engine db. The data will relay in
a dedicated dwh_osinfo table.
--- Additional comment from Yaniv Dary on 2013-06-25 08:59:58 EDT ---
This is a documentation bug. We need to add a guide to adding new OSs to the history database. Zac, which component to move this to?
its not clear if this is a documentation bug or coding is needed.
you need to remember the enums in dwh are also per locale for example.
I think a procedure to adding them by customer to dwh if adding OSs to OsInfo is good enough for now
What to test -
dwh history DB enum_translator table
or reports ?
(In reply to David Botzer from comment #6)
> What to test -
> dwh history DB enum_translator table
> or reports ?
history DB enum_translator table after adding custom os to rhevm.
Engine side is ok
Adding new custom OS is shown in both
Engine DB - TABLE dwh_osinfo
Webadmin - Create new VM OS
how to test in dwh/reports side
(In reply to Yaniv Dary from comment #7)
> (In reply to David Botzer from comment #6)
> > What to test -
> > documentation,
> > dwh history DB enum_translator table
> > or reports ?
> history DB enum_translator table after adding custom os to rhevm.
(In reply to Yaniv Dary from comment #9)
> (In reply to Yaniv Dary from comment #7)
> > (In reply to David Botzer from comment #6)
> > > What to test -
> > > documentation,
> > > dwh history DB enum_translator table
> > > or reports ?
> > history DB enum_translator table after adding custom os to rhevm.
> > Yaniv
Should be added to en_US OS_TYPE.
I cannot login to dwh history db, there is a problem with rhevm-dwh-setup
rhevm-dwh-setup gives error when creating a user or not:
2013-09-30 14:49:19::DEBUG::common_utils::777::root:: output = 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1a:4a:16:97:df brd ff:ff:ff:ff:ff:ff
inet 10.35.161.223/24 brd 10.35.161.255 scope global eth0
inet6 fe80::21a:4aff:fe16:97df/64 scope link
valid_lft forever preferred_lft forever
2013-09-30 14:49:19::DEBUG::common_utils::778::root:: stderr =
2013-09-30 14:49:19::DEBUG::common_utils::779::root:: retcode = 0
2013-09-30 14:49:19::DEBUG::common_utils::589::root:: Found IP Address: 10.35.161.223
2013-09-30 14:49:19::DEBUG::common_utils::735::root:: Executing command --> '/bin/su -l postgres -c /usr/bin/psql -U postgres -c "DROP ROLE if exists engine_history;"' in working directory '/etc/ovirt-engine/notifier'
2013-09-30 14:49:19::DEBUG::common_utils::777::root:: output =
2013-09-30 14:49:19::DEBUG::common_utils::778::root:: stderr = ERROR: role "engine_history" cannot be dropped because some objects depend on it
DETAIL: owner of database ovirt_engine_history
287 objects in database ovirt_engine_history
2013-09-30 14:49:19::DEBUG::common_utils::779::root:: retcode = 129
2013-09-30 14:49:19::ERROR::rhevm-dwh-setup::506::root:: Exception caught!
2013-09-30 14:49:19::ERROR::rhevm-dwh-setup::507::root:: Traceback (most recent call last):
File "/usr/bin/rhevm-dwh-setup", line 410, in main
File "/usr/share/ovirt-engine-dwh/common_utils.py", line 998, in createUser
File "/usr/share/ovirt-engine-dwh/common_utils.py", line 782, in execCmd
Exception: Return Code is not zero
history db enum_translator is not updated
Yaniv: please advise on the correct build
When is this due to be fix ?
if not current build, please move it to assign (or let me know and I will)
3.3/is16 This bug is fixed,
dwh history db - enum_translator table includes all OS_TYPES
Need to examine the following before I verify:
1. postgresql.conf is incomplete (Half) missing the connection config params
2. What build is this fix included in order to test it fully.
Created attachment 805838 [details]
DWH install successfully,
history DB enum_translator has the following only in English:
"OS_TYPE";1193;"en_US";"SUSE Linux Enterprise Server 11"
"OS_TYPE";1252;"en_US";"Ubuntu Precise Pangolin LTS"
"OS_TYPE";1253;"en_US";"Ubuntu Quantal Quetzal"
"OS_TYPE";1254;"en_US";"Ubuntu Raring Ringtails"
"OS_TYPE";1255;"en_US";"Ubuntu Saucy Salamander"
Should they include in all languages ?
This bug is currently attached to errata RHEA-2013:15116. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.
Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:
* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')
Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.
For further details on the Cause, Consequence, Fix, Result format please refer to:
Thanks in advance.
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.