Bug 985346

Summary: Share the engine's os info with DWH through a translation table
Product: Red Hat Enterprise Virtualization Manager Reporter: Roy Golan <rgolan>
Component: ovirt-engine-dwhAssignee: Yaniv Lavi <ylavi>
Status: CLOSED ERRATA QA Contact: Barak Dagan <bdagan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, bazulay, bdagan, cpelland, iheim, jkt, michal.skrivanek, pstehlik, Rhev-m-bugs, ylavi, zdover
Target Milestone: ---   
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: rhevm-dwh-3.3.0-12.el6ev.noarch.rpm Doc Type: Enhancement
Doc Text:
Custom virtual machine operating system information is now automatically synced to history database.
Story Points: ---
Clone Of: 977440 Environment:
Last Closed: 2014-01-21 14:59:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 977440    
Bug Blocks: 1019461    
Attachments:
Description Flags
half-sql none

Description Roy Golan 2013-07-17 10:30:19 UTC
+++ 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):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
DWH keeps its own translation based on the VmOsType enum and won't have any info
on new OSs

Expected results:
DWH will be able to read the mapping from the engine db. The data will relay in 
a dedicated dwh_osinfo table.

Additional info:

--- 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? 



Yaniv

Comment 1 Itamar Heim 2013-07-17 12:56:53 UTC
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

Comment 6 David Botzer 2013-09-30 10:29:26 UTC
What to test - 
documentation, 
dwh history DB enum_translator table 
or reports ?

Comment 7 Yaniv Lavi 2013-09-30 10:34:24 UTC
(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

Comment 8 David Botzer 2013-09-30 11:36:50 UTC
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

Comment 9 Yaniv Lavi 2013-09-30 11:39:33 UTC
(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

Comment 10 Yaniv Lavi 2013-09-30 11:40:29 UTC
(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.

Comment 11 David Botzer 2013-09-30 11:57:59 UTC
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
    option='createdb',
  File "/usr/share/ovirt-engine-dwh/common_utils.py", line 998, in createUser
    failOnError=True
  File "/usr/share/ovirt-engine-dwh/common_utils.py", line 782, in execCmd
    raise Exception(msg)
Exception: Return Code is not zero

Comment 12 David Botzer 2013-09-30 13:50:18 UTC
history db enum_translator is not updated
Yaniv: please advise on the correct build

Comment 13 David Botzer 2013-10-01 07:54:45 UTC
When is this due to be fix ?
if not current build, please move it to assign (or let me know and I will)

Comment 14 David Botzer 2013-10-01 10:53:05 UTC
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.

Comment 15 David Botzer 2013-10-01 10:53:31 UTC
Created attachment 805838 [details]
half-sql

Comment 16 David Botzer 2013-10-02 11:31:54 UTC
3.3/is17.1
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 ?
Please advise,

Comment 17 David Botzer 2013-10-03 04:28:34 UTC
Fixed, 3.3/is17.1

Comment 18 Charlie 2013-11-28 00:54:49 UTC
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:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 20 errata-xmlrpc 2014-01-21 14:59:23 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-2014-0036.html