Description of problem: When restoring the engine from backup on a different machine than the original one, where the DB user potentially exists but has a different password, the user is required to retrieve the old password from the restore file and alter the DB user's password accordingly. This process could be automated and made part of the script, by looking for the right file in the backup tar and retrieving the old password, then checking if that's the right password for the same DB user on the current machine - if it doesn't exist then create it with this password, if it does but the password doesn't match then ask the user interactively whether it's okay to change the DB user's password. This is not only more user-friendly, but also abstracts the format of the backup file away from the user (whereas currently they have to know it's a tar file). Version-Release number of selected component (if applicable): oVirt 3.4.0 RC.
Ofer, Didi, can we have this fixed in 3.4.0?
I do not think we'll do that for 3.4. We decided to not do provisioning in engine-backup's current (shell) implementation as it's a duplication of effort (as the engine's is in python). I think we'll only do this and similar significant changes when we re-implement this using python/ovirt-engine-setup-base. See bug #1064503 . Also, while I agree that using engine-backup --mode=restore is somewhat annoying in many common flows, "Officially", the description above is wrong: (In reply to Lior Vernia from comment #0) > Description of problem: > > When restoring the engine from backup on a different machine than the > original one, where the DB user potentially exists but has a different > password, the user is required to retrieve the old password from the restore > file and alter the DB user's password accordingly. No, that's not true. The user can pass the password of the existing user (parhaps after changing it if it's not known) using --change-db-credentials . > > This process could be automated and made part of the script, by looking for > the right file in the backup tar and retrieving the old password, then > checking if that's the right password for the same DB user on the current > machine - if it doesn't exist then create it with this password, if it does > but the password doesn't match then ask the user interactively whether it's > okay to change the DB user's password. I agree that it can be automated and would make the utility easier to use. > > This is not only more user-friendly, but also abstracts the format of the > backup file away from the user (whereas currently they have to know it's a > tar file). The format is abstracted using '--change-db-credentials'. We do not try to hide the format, though. I suggest to close this bug as duplicated of bug #1064503 . Makes sense? BTW, I recently added a section "Howto" to [1], you are welcome to review it. I also added this link to '--help'. [1] http://www.ovirt.org/Ovirt-engine-backup BTW, in RHEV 3.2 we back-ported engine-backup, dropped '--change-db-credentials' and instead added '--mode=getcredentials' which outputs the credentials backed up in the tarball. I'd rather not do that upstream because I think it's the wrong behavior, but am open to suggestions...
When restoring we cannot perform provisioning automatically as: 1. we may restore only product and not database. 2. we may restore to different machine keeping the previous database as remote. 3. we may restore to a machine that already running another instance of application. Restore is not about being user friendly but being safe and predictable.
Closing per comment 2 and comment 3. *** This bug has been marked as a duplicate of bug 1064503 ***