Bug 1229398
| Summary: | [engine-backup] reports fails after restore with --change-dwh-db-credentials | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ulhas Surse <usurse> |
| Component: | ovirt-engine-reports | Assignee: | Yedidyah Bar David <didi> |
| Status: | CLOSED ERRATA | QA Contact: | Lukas Svaty <lsvaty> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.4.5 | CC: | bazulay, bmcclain, dfediuck, didi, lsurette, melewis, pstehlik, rbalakri, Rhev-m-bugs, sbonazzo, yeylon, ykaul, ylavi |
| Target Milestone: | ovirt-3.6.0-rc | ||
| Target Release: | 3.6.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Previously, the reports plugin for engine-setup did not recreate the data warehouse data source on upgrade, but instead kept the existing data sources. There was an option in engine-backup to restore data warehouse with changed database credentials, but this relied on engine-setup to configure reports to be able to access the data warehouse database. This meant that after restoring a system with a data warehouse and reports, where the data warehouse was restored to a different database, reports could not access the data warehouse database. Now, the reports engine-setup plugin has been changed to always create the data warehouse data source, so that reports can access the data warehouse database.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-09 21:19:47 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1254639 | ||
| Bug Blocks: | |||
Now reproduced under 3.4.5. This bug is unrelated to others linked above. It's caused by [1] - on upgrade, we export the existing dwh datasource, then deploy new jasper, then import the datasource. This means that changing dwh creds will not affect those saved there. Yaniv - any reason to save/restore them and not just recreate? Do we (want to) support adding new datasources, or editing them? If we do, we'll have to somehow edit it to get the new credentials. [1] https://gerrit.ovirt.org/gitweb?p=ovirt-reports.git;a=blob;f=packaging/setup/plugins/ovirt-engine-setup/ovirt-engine-reports/jasper/deploy.py;h=d2299fcce0e72ee8b2fa2363e4dd83935e17a69a;hb=HEAD#l327 Also tried to find a workaround by editing the table jijdbcdatasource directly, but it's "encrypted" (one might say obfuscated) there and I can't easily find out how. A possible workaround is to export the datasources, editing, then importing back. We can even add this to the reports-tool... Yaniv - please help with this too if you think it's important (or you can easily point to a solution). BTW, depending on the accepted solution, we might change the component - if recreating dwh datasource, the fix will be in reports (and not in engine-backup). (In reply to Yedidyah Bar David from comment #1) > Now reproduced under 3.4.5. > > This bug is unrelated to others linked above. > > It's caused by [1] - on upgrade, we export the existing dwh datasource, then > deploy new jasper, then import the datasource. > > This means that changing dwh creds will not affect those saved there. > > Yaniv - any reason to save/restore them and not just recreate? Do we (want > to) support adding new datasources, or editing them? We will not support new user datasources. I would only object to save/restore them due to stability concerns that flow we do not think of will break. > > If we do, we'll have to somehow edit it to get the new credentials. > > [1] > https://gerrit.ovirt.org/gitweb?p=ovirt-reports.git;a=blob;f=packaging/setup/ > plugins/ovirt-engine-setup/ovirt-engine-reports/jasper/deploy.py; > h=d2299fcce0e72ee8b2fa2363e4dd83935e17a69a;hb=HEAD#l327 > > Also tried to find a workaround by editing the table jijdbcdatasource > directly, but it's "encrypted" (one might say obfuscated) there and I can't > easily find out how. A possible workaround is to export the datasources, > editing, then importing back. We can even add this to the reports-tool... > Yaniv - please help with this too if you think it's important (or you can > easily point to a solution). We should not touch the Jasper tables. We can create a simple kbase on how to change the dwh cred after restore, I do not consider this a major issue. This can be admin user edited via the UI. (In reply to Yaniv Dary from comment #3) > We will not support new user datasources. I would only object to > save/restore them due to stability concerns that flow we do not think of > will break. Not sure I follow. You object to save/restore? Or to always rewrite? Already explained what flow will break: If a user somehow manually edits the datasource. In previous versions (e.g. 3.2->3.3 upgrade) we didn't keep it but rewritten. So the principle flow was already used (in a different code base). Moving to post for now. The linked patch rewrites the datasource on upgrades. Since there a workaround and customer case is closed, only fixing for 3.6. Can you confirm these verification steps? Tried also changing users credentials with no difference of restore, however I believe step 2 is not essential. verification steps: 1. Create backup: # engine-backup --mode=backup --file=/rootbackup.tar.bz2 --log=/tmp/backup.log 2. Resore: # engine-backup --mode=restore --file=/root/backup.tar.bz2 --scope=all --log=/tmp/rhevm_restore.log --db-host=localhost --db-user=newengine --db-password=newpass --db-name=newengine --dwh-db-host=localhost --dwh-db-name=newdwh --dwh-db-user=newdwh --dwh-db-password=newpass --change-db-credentials --change-dwh-db-credentials Result log: 2015-08-20 11:43:13 12488: Start of engine-backup mode restore scope all file /root/backup.tgx 2015-08-20 11:43:13 12488: OUTPUT: Preparing to restore: 2015-08-20 11:43:13 12488: OUTPUT: - Setting credentials for Engine database 'newengine' 2015-08-20 11:43:13 12488: pg_cmd running: psql -w -U newengine -h 127.0.0.1 -p 5432 newengine -c select 1 psql: FATAL: Ident authentication failed for user "newengine" 2015-08-20 11:43:13 12488: FATAL: Can't connect to database 'newengine'. Please see '/usr/bin/engine-backup --help'. After discussion on this bug with assignee moving back to ON_QA will be verified after blocker is solved. The fix was in reports, changing component. (In reply to Yaniv Dary from comment #5) > Since there a workaround and customer case is closed, only fixing for 3.6. What's the workaround? I didn't suggest one. I just said I looked for one and failed to find... I understood from you that it's possible to manually edit the data source from the web interface. If indeed, please verify and document. Thanks! (In reply to Yedidyah Bar David from comment #10) > (In reply to Yaniv Dary from comment #5) > > Since there a workaround and customer case is closed, only fixing for 3.6. > > What's the workaround? > > I didn't suggest one. I just said I looked for one and failed to find... > > I understood from you that it's possible to manually edit the data source > from the web interface. If indeed, please verify and document. Thanks! Using admin user. Go to 'view' and press on 'repository'. Drill to folder 'RHEVM Reports'->'Resources'->'JDBC'->'Data Sources'->'oVirt History'. Edit the resource and setup the db location. Press save. "has be" -> "was" plus a few commas :-) Thanks for the feedback. :) 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. https://rhn.redhat.com/errata/RHEA-2016-0425.html |
Description of problem: restore of reports fails if using change-{,dwh}-db-credentials and --change-reports-db-credentials options. Version-Release number of selected component (if applicable): RHEVM 3.4.5 How reproducible: always Steps to Reproduce: 1. Create backup. 2. Creating db and user roles and set new passwd. Decide to handle the new password when recovering using 'engine-backup 3. restore with: # engine-backup --mode=restore --scope=all --file=/tmp/rhevm-backup/backup.20150513100001.tar.bz2 --log=/tmp/restore.log --change-db-credentials --db-host=localhost --db-user=engine --db-password=recvrTesTEngine --db-name=engine --change-dwh-db-credentials --dwh-db-host=localhost --dwh-db-user=ovirt_engine_history --dwh-db-password=recvrTesTdwh --dwh-db-name=ovirt_engine_history --change-reports-db-credentials --reports-db-host=localhost --reports-db-user=ovirt_engine_reports --reports-db-password=recvrTesTreports --reports-db-name=ovirt_engine_reports This will not set password for reports. Actual results: Unexpected error com.jaspersoft.jasperserver.api.JSExeption:jesxecption.error.creating.connection Expected results: The restore should work. Additional info: The same ovirt bugzilla exists: [engine-backup] restore fails if using change-{,dwh}-db-credentials and previous user exists https://bugzilla.redhat.com/show_bug.cgi?id=1212752