Description of problem: 'engine-backup --mode=restore' does not do postgres provisioning. We decided to keep it like that because it's written in shell, which would have required re-implementing the provisioning code of engine-setup (written in python). engine-setup should be able to also restore backups done with 'engine-backup --mode=backup'. Comments about interface, behavior etc. are welcome. I set target version to 3.5.0 but if we are quick enough we might backport to 3.4.
Why? where does it come from? What if database is remote? Is this hosted engine thing?
(In reply to Alon Bar-Lev from comment #1) > Why? where does it come from? From answering enough questions regarding this... And I am pretty certain it was your idea which you quickly talked about some time ago :-) > > What if database is remote? What if it is? If it's empty, we use it, if not, abort. Just like normal setup. > > Is this hosted engine thing? Will obviously be useful for that too, but it was never discussed specifically in this context, afaik.
I never addressed engine-setup. You can re-write the restore using otopi... but I really think that it will make it much more complex than it should both to maintain and actual restore. I prefer to keep all as simple as we can, going this route will be never ending project.
Very well. Changing the summary accordingly. Solving it probably means re-implementing based on otopi.
*** Bug 1064903 has been marked as a duplicate of this bug. ***
(In reply to Alon Bar-Lev from comment #3) > I never addressed engine-setup. BTW, perhaps you didn't, but I did find this mentioned here [1]. So it's not just my weird imagination. [1] http://www.ovirt.org/Ovirt-engine-backup
*** Bug 1073425 has been marked as a duplicate of this bug. ***
*** Bug 1099240 has been marked as a duplicate of this bug. ***
See the long discussion under "DB Credentials" on this page: http://www.ovirt.org/Ovirt-engine-backup I think this is an indication of why this feature would be of value to people. - People expect engine-backup restore to create the database for them (since that's what restores usually do - recreate the original) - It's very complicated for people to work out for themselves what is required in absence of this feature. If all that's required is the (optional) recreation of the database, wouldn't something similar to this be sufficient: http://www.ovirt.org/Backup_engine_db Obviously you would not need to backup the content of the DB, since that's already done, but doesn't this also recreate/provision the database? Keep in mind that the default engine-setup creates a local database, so that's what the vast majority of users will have. A solution for those users would go a long way to making life easier for the community. I doubt it is necessary to restore a remote database (you can always go to the place the database resides, and restore it there). IMO it would be OK to refuse to provision if the db was remote.
I just can +1 Bobs comment. Furthermore: It's just more consistent within ovirt: the engine-setup doesn't expect a precreated db, why should engine-backup --mode=restore expect it?
didi, can't we simply dump with db\admin user create?
(In reply to Yaniv Dary from comment #11) > didi, can't we simply dump with db\admin user create? This will not be enough - you have to take care of other things, such as pg_hba.conf.
Decided to give up for now on rewriting engine-backup, instead adding a utility in python to provision a database and call that one from engine-backup.
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.