Bug 1064503 - [RFE] 'engine-backup --mode=restore' should allow provisioning
Summary: [RFE] 'engine-backup --mode=restore' should allow provisioning
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer
Version: 3.4
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.6.0
Assignee: Yedidyah Bar David
QA Contact: Lukas Svaty
URL:
Whiteboard: integration
: 1073425 1099240 (view as bug list)
Depends On:
Blocks: 1073421 1263955
TreeView+ depends on / blocked
 
Reported: 2014-02-12 17:55 UTC by Yedidyah Bar David
Modified: 2016-01-28 03:57 UTC (History)
14 users (show)

Fixed In Version: ovirt-3.6.0-alpha1.2
Doc Type: Enhancement
Doc Text:
Feature: Allow provisioning databases with engine-backup during restore. Reason: Manually provisioning a database is a tedious task, and users expect it to happen automatically (as is possible/default with engine-setup). Result: A utility to provision a database, based on existing engine-setup code doing this, was added. This utility is now optionally called by engine-backup during restore, if one or more of the following new options are used: --provision-db --provision-dwh-db --provision-reports-db This is currently limited to cases where the database was originally provisioned by engine-setup.
Clone Of:
Environment:
Last Closed: 2015-11-04 11:29:46 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 36377 0 master ABANDONED packaging: Otopi-based engine-backup Never
oVirt gerrit 40451 0 master MERGED packaging: add provisiondb Never
oVirt gerrit 40471 0 master MERGED packaging: engine-backup: Allow provisioning Never

Description Yedidyah Bar David 2014-02-12 17:55:04 UTC
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.

Comment 1 Alon Bar-Lev 2014-02-12 17:57:52 UTC
Why? where does it come from?

What if database is remote?

Is this hosted engine thing?

Comment 2 Yedidyah Bar David 2014-02-12 18:07:35 UTC
(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.

Comment 3 Alon Bar-Lev 2014-02-12 18:13:29 UTC
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.

Comment 4 Yedidyah Bar David 2014-02-13 10:43:09 UTC
Very well. Changing the summary accordingly. Solving it probably means re-implementing based on otopi.

Comment 5 Yedidyah Bar David 2014-02-13 14:51:28 UTC
*** Bug 1064903 has been marked as a duplicate of this bug. ***

Comment 6 Yedidyah Bar David 2014-02-17 10:17:39 UTC
(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

Comment 7 Doron Fediuck 2014-03-20 09:19:09 UTC
*** Bug 1073425 has been marked as a duplicate of this bug. ***

Comment 8 Yedidyah Bar David 2014-05-20 09:30:40 UTC
*** Bug 1099240 has been marked as a duplicate of this bug. ***

Comment 9 Bob Doolittle 2014-05-20 14:25:50 UTC
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.

Comment 10 Sven Kieske 2014-05-20 14:39:14 UTC
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?

Comment 11 Yaniv Lavi 2015-04-07 08:51:17 UTC
didi, can't we simply dump with db\admin user create?

Comment 12 Yedidyah Bar David 2015-04-08 05:37:59 UTC
(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.

Comment 13 Yedidyah Bar David 2015-05-04 14:11:29 UTC
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.

Comment 14 Sandro Bonazzola 2015-11-04 11:29:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.