Bug 1118322 - reports upgrade on separate host asks again dwh db credentials
Summary: reports upgrade on separate host asks again dwh db credentials
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-reports
Version: 3.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.1
Assignee: Yedidyah Bar David
QA Contact: Petr Matyáš
Whiteboard: integration
Depends On:
Blocks: 1156040
TreeView+ depends on / blocked
Reported: 2014-07-10 12:52 UTC by Yedidyah Bar David
Modified: 2015-01-21 16:01 UTC (History)
10 users (show)

Fixed In Version: vt8
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1128787 1156040 (view as bug list)
Last Closed: 2015-01-21 16:01:51 UTC
oVirt Team: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 34514 0 master MERGED packaging: setup: keep and use dwh db credentials Never
oVirt gerrit 34543 0 ovirt-engine-reports-3.5 MERGED packaging: setup: keep and use dwh db credentials Never

Description Yedidyah Bar David 2014-07-10 12:52:44 UTC
Description of problem:

When Reports is setup on a separate host we ask for engine/dwh db credentials. Running again (e.g. for upgrade) asks again.

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

Current master

How reproducible:


Steps to Reproduce:
1. Setup engine and dwh
2. Setup Reports on a separate host
3. Run engine-setup again on the Reports host

Actual results:

Asks again for engine/dwh credentials

Expected results:

Does not ask for engine/dwh credentials

Additional info:

Engine keeps its credentials in /etc/ovirt-engine/engine.conf.d/10-setup-database.conf .
DWH keeps both its own credentials and the engine's in /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf .

Reports does not keep db credentials in a similar file. Instead, it creates a temporary jasperreports conf dir and deploys it. This causes jasper to generate various different configuration files, under /var/lib/ovirt-engine-reports , many of which contain its own db credentials. On upgrade (next run of engine-setup), we read a specific one of them, /var/lib/ovirt-engine-reports/build-conf/master.properties , and therefore do not need to ask for them again.

DWH db creds are not saved by reports in any conf file, but are saved in the reports db in the table jijdbcdatasource (in a not-trivial-to-parse format).

Engine db creds are not saved anywhere, and are actually currently used only for updating the vdc_option table on the engine - so we might decide to not ask them at all and tell the user to update it with engine-config.

A minimal solution is to stop asking for engine creds and tell the user to run engine-config, and to read jijdbcdatasource for the dwh creds. A better (imo?) solution might be to create a new file /etc/ovirt-engine-reports/ovirt-engine-reports.d/10-setup-database.conf, keep there all credentials, and also use it for reports (instead of master.properties) - this will also allow refactoring the existing functions that read (and write?) these credentials to a single common function and simple wrappers for each component.

Comment 1 movciari 2014-10-30 13:18:30 UTC
which solution did you implement and which versions should i test? should i wait for vt9 so i can test update from vt8 to vt9?

Comment 2 Yedidyah Bar David 2014-10-30 14:23:46 UTC
The dwh credentials are now written to /etc/ovirt-engine-reports/ovirt-engine-reports.conf.d/10-setup-database.conf .

This bug is upstream, not sure what happens downstream. Perhaps it's already in vt8.

If you upgrade from a version without the fix (e.g. upstream 3.5.0 or downstream vt7(?)) to a version with the fix, it will ask again dwh credentials and write them to that file. The next run will not need to ask again. For verification, you do not need to really upgrade (to a new version), just running again and seeing that it does not ask for the credentials is enough.

Comment 3 Petr Matyáš 2014-12-09 14:48:54 UTC
Verified with 1156040

Comment 4 Sandro Bonazzola 2015-01-21 16:01:51 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.

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