Created attachment 1020521 [details] logs Description of problem: unable to restore if backup contains read only user for DWH DB access, found hardly while restoring our long running brq-setup (existing since 3.0). # engine-backup --mode=restore --file=backup --log=restore.log Preparing to restore: - Unpacking file 'backup' Restoring: - Files - Engine database 'engine' - DWH database 'ovirt_engine_history' FATAL: Errors while restoring database ovirt_engine_history ... ERROR: role "readonlyuser" does not exist REVOKE REVOKE GRANT ERROR: role "readonlyuser" does not exist 2015-04-30 11:46:56 924: FATAL: Errors while restoring database ovirt_engine_history Version-Release number of selected component (if applicable): 3.5.1 How reproducible: 100% Steps to Reproduce: 1. install 3.3 rhevm, rhevm-dwh, rhevm-reports, create read-only user for dwh db access 2. upgrade env to 3.4 -> 3.5.1 3. engine-backup --mode=backup ... (save for latest somewhere) 4. clean os, *install only* 3.5.1 rhevm, rhevm-dwh, rhevm-reports 5. get the backup, engine-backup --mode=restore ... Actual results: restore fails because dwh ro db user does not exist Expected results: should work or at least it should do some pre-check for all prereqs existing Additional info:
fyi https://bugzilla.redhat.com/show_bug.cgi?id=1092388
Already fixed in 3.6 by the fix for bug 1212752. The fix was trivial - just passing '--no-owner'. We might want to note somewhere, though, that with this, restore will not anymore (try to, and fail to) restore other users and grants. Thus, if you have in the db more than the minimum set of users/grants created by engine-setup, it's up to you to backup/restore these if needed.
Moving back to NEW for consideration whether we want this in 3.5.
Moving to modified, as it's already fixed in 3.6, see comment 2.
This bug has been cloned to the z-stream bug #1220791
This is a duplicate of bug 1212752. Leaving open/testonly as it's a different product.
(In reply to Yedidyah Bar David from comment #6) > This is a duplicate of bug 1212752. > > Leaving open/testonly as it's a different product. Sorry, it's not a duplicate, and requires another fix.
Setting require-doc-text -, because it's already fixed in z-stream bug 1220791. Copying the doc text for reference. Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them). Result: restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant. Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html
ok, rhevm-tools-3.6.0.3-0.1.el6.noarch i have engine/dwh/reports setup from 3.3 and upgraded to 3.4, 3.5 and later on to 3.6. dwh db had original r/o user from 3.3 and i also created one manually as described in the bottom on #8. # engine-backup --mode=restore --scope=all --file=backup01 --log=restore_backup01.log Preparing to restore: - Unpacking file 'backup01' Restoring: - Files - Engine database 'engine' - Cleaning up temporary tables in engine database 'engine' - Resetting DwhCurrentlyRunning in dwh_history_timekeeping in engine database - DWH database 'ovirt_engine_history' - Reports database 'rhevmreports' You should now run engine-setup. Done.
clarification: after continuous upgrade path ended in 3.6, i did backup, engine-clean, dropped all dbs/roles, manually created dbs/roles and then i did restore via engine-backup (only in this way it should have failed).