Red Hat Bugzilla – Bug 1049468
[REPORTS-SETUP] When upgrading from 3.2/3.1 and using postgres user as remote user, setup fails.
Last modified: 2015-09-22 09:10 EDT
Description of problem: When upgrading from rhevm-reports 3.2/3.1 and using postgres user as remote user, setup fails. This is due to inability to drop cascade on clean of db with user postgres. Version-Release number of selected component (if applicable): 3.3.0 How reproducible: Always Steps to Reproduce: 1. install reports 3.2 with remote db and user postgres 2. upgrade to 3.3 reports. Actual results: fails on db cleanup Expected results: should fail on postgres user selection or replace user to temp user on objects in the db and then drop them, so cleanup will work or drop and create the db. Additional info:
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