Bug 1217402

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).