Bug 1024707

Another difference: iptables does not contain ports of postgresql and websocket-proxy

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

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

(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

> 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?

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

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.

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.

Verified on RHEVM3.3 IS27 based on reproduce instructions in description.

Closing - RHEV 3.3 Released

Closing - RHEV 3.3 Released