DescriptionYedidyah Bar David
2014-08-11 14:32:38 UTC
+++ This bug was initially created as a clone of Bug #1118322 +++
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:
Always
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.