Bug 1024707 - engine-setup after 'engine-backup --mode=restore' does not fix everything
engine-setup after 'engine-backup --mode=restore' does not fix everything
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.3.0
Assigned To: Yedidyah Bar David
sefi litmanovich
integration
: Triaged
Depends On:
Blocks: 3.3rc1
  Show dependency treegraph
 
Reported: 2013-10-30 05:44 EDT by Yedidyah Bar David
Modified: 2015-08-13 02:19 EDT (History)
11 users (show)

See Also:
Fixed In Version: is27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 20736 None None None Never
oVirt gerrit 20737 None None None Never
oVirt gerrit 22181 None None None Never

  None (edit)
Description Yedidyah Bar David 2013-10-30 05:44:38 EDT
Description of problem:

A successful engine-setup after a successful restore should leave the machine in basically the same state the machine on which was done was then.

I now tried this in a specific scenario and there was this difference:
The services postgresql and websocket-proxy were not configured to automatically start on reboot.

Other scenarios should be tested and added to this bug if differences are found.

Notable accepted exceptions:
- The ISO domain, if configured, is not backed up by backup and so is not available on restore.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
On machine A:
1. engine-setup with local, setup-provisioned postgresql and websocket-proxy enabled
2. engine-backup --mode=backup --file=file1
3. copy file1 to machine B
On machine B:
1. engine-backup --mode=restore --file=file1
2. engine-setup

Actual results:

postgresql and websocket-proxy are not configured to start on boot

Expected results:

Machine B should be configured identically to machine A

Additional info:

Other services _are_ configured to start on boot in this scenario:
iptables
ovirt-engine
httpd
nfs
Comment 1 Yedidyah Bar David 2013-10-30 08:50:49 EDT
Another difference: iptables does not contain ports of postgresql and websocket-proxy
Comment 2 Alon Bar-Lev 2013-10-30 08:56:42 EDT
(In reply to Yedidyah Bar David from comment #1)
> Another difference: iptables does not contain ports of postgresql and
> websocket-proxy

backup/restore is not a machine backup restore.

from the devack, I understand where you heading and it is probably abuse of the backup/restore.
Comment 3 Yedidyah Bar David 2013-10-30 09:15:04 EDT
(In reply to Alon Bar-Lev from comment #2)
> (In reply to Yedidyah Bar David from comment #1)
> > Another difference: iptables does not contain ports of postgresql and
> > websocket-proxy
> 
> backup/restore is not a machine backup restore.

Indeed. I explained very well what I expect - to have
1. engine-setup
2. engine-backup --mode=restore + engine-setup
to make the same changes to the machine.

If (1.) changes /etc/sysconfig/iptables, I expect (2.) to do the same. And currently, (2.) changes iptables, just not doing all the changes (1.) does.

If you think otherwise, state clearly what you expect.

> 
> from the devack, I understand where you heading and it is probably abuse of
> the backup/restore.

It's not a secret that I am working on this as a tool for migration to hosted engine. If you ask me, in the next two years, a very large percent of the actual uses of restore will be for this migration. But I think that this bug (and related ones) are very much relevant for any reasonable use case.
Comment 4 Alon Bar-Lev 2013-10-30 09:32:07 EDT
(In reply to Yedidyah Bar David from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> > (In reply to Yedidyah Bar David from comment #1)
> > > Another difference: iptables does not contain ports of postgresql and
> > > websocket-proxy
> > 
> > backup/restore is not a machine backup restore.
> 
> Indeed. I explained very well what I expect - to have
> 1. engine-setup
> 2. engine-backup --mode=restore + engine-setup
> to make the same changes to the machine.
> 
> If (1.) changes /etc/sysconfig/iptables, I expect (2.) to do the same. And
> currently, (2.) changes iptables, just not doing all the changes (1.) does.
> 
> If you think otherwise, state clearly what you expect.
> 
> > 
> > from the devack, I understand where you heading and it is probably abuse of
> > the backup/restore.
> 
> It's not a secret that I am working on this as a tool for migration to
> hosted engine. If you ask me, in the next two years, a very large percent of
> the actual uses of restore will be for this migration. But I think that this
> bug (and related ones) are very much relevant for any reasonable use case.

I disagree.

We change the iptables as a service to user, it should not be part of backup just like any other change we are doing (nfs exports and such).

You should split the hosted engine into wrapper script that also copy other artifacts that are needed, hosted engine is a hack anyway...

If we go to your direction we should develop system backup/restore utility, which is way out of the scope of our project.

An acceptable solution should be running setup again after restore and select an option such as "re-set firewall" as a service to user.

A sequence of backup for every product is:

1. setup product
2. backup machine template
3. periodic backup of product

A restore sequence is:

1. restore machine template
2. restore latest product backup
Comment 5 Yedidyah Bar David 2013-10-30 09:45:47 EDT
> A sequence of backup for every product is:
> 
> 1. setup product
> 2. backup machine template
> 3. periodic backup of product
> 
> A restore sequence is:
> 
> 1. restore machine template
> 2. restore latest product backup

For this, db backup/restore is enough. Why do we deal at all with all the rest?
Comment 6 Alon Bar-Lev 2013-10-30 09:50:49 EDT
(In reply to Yedidyah Bar David from comment #5)
> > A sequence of backup for every product is:
> > 
> > 1. setup product
> > 2. backup machine template
> > 3. periodic backup of product
> > 
> > A restore sequence is:
> > 
> > 1. restore machine template
> > 2. restore latest product backup
> 
> For this, db backup/restore is enough. Why do we deal at all with all the
> rest?

Not true. Product settings may be in files or database should be included in product backup.

Example: pki database, lib artifacts.
Comment 9 Yedidyah Bar David 2013-12-09 03:18:11 EST
http://gerrit.ovirt.org/20737, for firewall configuration, was now merged.

It changes the behavior of engine-setup in the following way:

1. We added a question
          Setup can automatically configure the firewall on this system.
          Note: automatic configuration of the firewall may overwrite current settings.
          Do you want Setup to configure the firewall? (Yes, No) [Yes]:
The answer to this question is not saved for future upgrades, so it's asked on every upgrade. Users can still provide an answer in a custom answer file.
2. If the reply is 'no', no firewall configuration is done. In particular:
If on setup the firewall was configured ("Yes"), and on a later upgrade the reply was "No", it won't be touched, even if the upgrade added services which might need to be accessible from outside.
3. If the reply is "Yes":
3.1. The firewall will be updated also on upgrades.
3.2. Unlike before, the user will be provided with a list of firewall managers. This list:
3.2.1. Is comprised only of supported (in the code). This currently includes 'iptables' and 'firewalld', but the system was extended to allow adding other managers in the future, even as plugins provided by external packages.
3.2.2. Can be further limited with a configuration option of 'valid' managers, e.g. to show only 'iptables' even if firewalld is detected.
3.2.3. If there are 'active' managers, only these are listed, and if there is exactly one 'active', it's automatically selected without a question.
3.2.4. This means that if a system has both firewalld and iptables, and one of them is active, the user will not be able to choose the other and switch.
3.2.5. Actually the previous point is not true - using the option in 3.2.2. a user can limit to only have the other manager as 'valid'.
4. In any case, the choice of which manager to use is kept for future upgrades and is not asked again.
5. The above also means that if on setup (or one or more upgrades) the user did not update the firewall (and did not select a manager), then on the next upgrade they can still select 'Yes' and choose a firewall manager, and the firewall will be configured, and the choice of which manager to use will be kept for further upgrades. So now 'engine-setup' can also be used for merely configuring the firewall.
Comment 10 Yedidyah Bar David 2013-12-09 03:20:15 EST
Regarding enabling services - it was decided to not do this now on upgrade. Users that use 'engine-backup --mode=restore && engine-setup' will have to enable some services (postgresql and websocket-proxy) manually, as needed.
Comment 11 sefi litmanovich 2013-12-16 10:14:39 EST
Verified on RHEVM3.3 IS27 based on reproduce instructions in description.
Comment 12 Itamar Heim 2014-01-21 17:26:44 EST
Closing - RHEV 3.3 Released
Comment 13 Itamar Heim 2014-01-21 17:30:03 EST
Closing - RHEV 3.3 Released

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