Bug 1049468
| Summary: | [REPORTS-SETUP] When upgrading from 3.2/3.1 and using postgres user as remote user, setup fails. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yaniv Lavi <ylavi> |
| Component: | ovirt-engine-reports | Assignee: | Yedidyah Bar David <didi> |
| Status: | CLOSED ERRATA | QA Contact: | Tareq Alayan <talayan> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.3.0 | CC: | acathrow, adahms, bazulay, iheim, lyarwood, pep, pstehlik, Rhev-m-bugs, sbonazzo, scohen, yeylon |
| Target Milestone: | --- | ||
| Target Release: | 3.3.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | integration | ||
| Fixed In Version: | IS31 - rhevm-reports-3.3.0-28.el6ev.noarch.rpm | Doc Type: | Bug Fix |
| Doc Text: |
Previously, setup would fail when upgrading rhevm-reports from version 3.2 using the postgres user as the remote user. This was due to an inability to drop cascade on cleaning the database as part of the upgrade. Now, rhevm-reports-setup uses cleandb.sh from dbscripts, which correctly drops all objects one-by-one.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-21 14:57:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1049654 | ||
| Bug Blocks: | 1056111 | ||
|
Description
Yaniv Lavi
2014-01-07 15:24:20 UTC
Some possible courses of actions discussed today: 1. Do nothing. setup will fail, seems like no harm will be done, but the user will be left "hanging". 2. Fail setup with a suitable message including information about what to do - either directly by setup or pointing to some article. 3. Somehow fix the bug and continue the setup with postgres. 4. Create a new user (similarly to a local database), try to connect with it to the database, and if this fails, ask the user to edit pg_hba.conf and restart postgres on the db server. (3.) is obviously simplest for the user. (4.) is the cleanest option, aligning db access with that of a new install and of an upgrade with a local database. To do this really cleanly, we should do the same also in the engine and reports. I did not check what happens there, but am pretty certain some work is needed. (2.) is probably the minimum. BTW, I now noticed that in 3.2, if user chose remote database, the default username was postgres. So I wouldn't be surprised if this scenario (remote postgres user) is actually very common, contrary to what I thought earlier. I am now testing #3 - drop/create database instead of drop owned by user cacade. verified on rhevm-dwh-3.3.0-28.el6ev.noarch rhevm-reports-3.3.0-28.el6ev.noarch successfully installed 3.3 reports on 3.2 upgraded env. doctext: Dropped '3.1' as our tests indicate there is no difference between '3.1->3.2->3.3' and 'clean 3.2->3.3' and I'd rather not confuse the users into thinking that a direct upgrade 3.1->3.3 is possible. 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-0035.html |