Bug 1422980

It doesn't have many other /etc configuration files backed up as well, we are only backing up oVirt/RHV items. 

Can you clarify why is this file and not others under /etc? 

What if I'm using ntpd?

*** Bug 1422978 has been marked as a duplicate of this bug. ***

> Can you clarify why is this file and not others under /etc? 

Because oVirt/RHEV will be more reliable if the engine clock is kept in sync due to our wide usage of SSL.
Because we support GSSAPI and clock skew will break that functionality.

> What if I'm using ntpd?

Let's say both chrony.conf and ntp.conf should be in the backup archive if present. 

"As a RHV administrator, I need ntp or chrony-based timekeeping to be restored when I restore the engine from backup".

(In reply to François Cami from comment #3)
> > Can you clarify why is this file and not others under /etc? 
> 
> Because oVirt/RHEV will be more reliable if the engine clock is kept in sync
> due to our wide usage of SSL.
> Because we support GSSAPI and clock skew will break that functionality.

So nothing for Kerberos?

> 
> > What if I'm using ntpd?
> 
> Let's say both chrony.conf and ntp.conf should be in the backup archive if
> present. 
> 
> "As a RHV administrator, I need ntp or chrony-based timekeeping to be
> restored when I restore the engine from backup".

> So nothing for Kerberos?

If I'm not mistaken this should be the subject of another RFE.

As it stands restoring chrony or ntp functionality from the backup would result in a more reliable engine - less prone to time drift.

I'd rather not backup and restore /etc completely because as we rebase the hosted-engine image from different RHEL versions this will not work.

I'd rather pick up the pieces that we really need:
* timekeeping => chrony.conf & ntp.conf
* hosts file

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

As the current maintainer of engine-backup, and a previously-long-time-sysadmin, I tend to disagree with current bug's request.

I think now and here would be a very good time to discuss criteria for inclusion of configuration files in engine-backup.

Until very recently, although such a discussion was never held AFAIK, these were, more-or-less:

1. All of /etc/*ovirt*, as applicable. These are "obviously" owned by us, should hopefully not raise questions.

2. Everything that might be automatically changed by engine-setup, depending on the answers provided for the questions it asks. This includes e.g. configuration for httpd.

Broadly, the following two flows should have resulted in semi-identical machines:

I.
Install OS+engine
engine-setup
engine-backup to file F1

II.
Install OS+engine
engine-backup restore from F1
engine-setup

Then, we reluctantly changed this recently, in bug 1693816, to include:

3. Everything that might be changed manually by the user when following the documentation. Ideally, this should not be needed - such pieces of documentation should also include instructions to add the files they suggest to create to the list of files backed up and restored by engine-backup. But doing this seemed too difficult at the time (see that bug), so we decided it's enough to add to the built-in list *and* mention that in the documentation, see doc bug 1700655.

As an admin, I think that if I know that I need some custom configuration/stuff in the engine (or any other) machine for installation, and engine-backup is strictly presented as a tool to backup the engine, I would expect to be able to, and have to, do these custom stuff during restore as well.

For standalone engines, I think this is obvious, and does not require that much more discussion.

For hosted-engine, either during restore from backup, or during (now obsolete, original reason for current bug, might be relevant again soon in the upgrade to RHEL8) migration to a newer OS, we'll soon prompt the admin to continue, thus letting them do whatever they need, see bug 1686575, and specifically https://gerrit.ovirt.org/100269 .

Thus, I propose CLOSE NOTABUG.

See https://bugzilla.redhat.com/show_bug.cgi?id=1422980#c3

You can decide to close NOTABUG but it would be better than to display a warning if no working ntpd/chronyd configuration is detected post-restore then.
This will happen after any migration done in environments without Internet access.

(In reply to François Cami from comment #11)
> See https://bugzilla.redhat.com/show_bug.cgi?id=1422980#c3

Yes, I did read all of current bug before writing comment 10. But, as kaul wrote two years ago, where do you stop? kerberos? ldap? custom networking configuration? What about custom backup/monitoring agents etc. - these will quite likely break as well if you do not backup/restore their configuration, right? That's why I do not want to discuss NTP, but to get an agreement about what this tool (engine-backup) is actually supposed to do, and what it's not supposed to do but leave to others.

> 
> You can decide to close NOTABUG but it would be better than to display a
> warning if no working ntpd/chronyd configuration is detected post-restore
> then.

Warning at which point? If restore is called from within hosted-engine, the user will never see it.

> This will happen after any migration done in environments without Internet
> access.

An update: I now verified that you can actually do configure engine-backup to backup whatever you want, and that it always restores everything that it backed up. See bug 1715767 comment 3. For current bug, this should be something like:

# mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d

# cat << __EOF__ >> /etc/ovirt-engine-backup/engine-backup-config.d/ntp-chrony.sh
BACKUP_PATHS="\${BACKUP_PATHS}
/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"
__EOF__

This can be added to docs etc. as an example/appendix/whatever. Makes sense?

> where do you stop? kerberos? ldap? custom networking configuration?

I'm not sure there is a good answer to that!
However kerberos/ldap are related to being able to log in to the engine while a broken ntp/chrony configuration will result in the engine not being able to manage the hosts (IIRC). So ntp.conf/chrony.conf and ldap/kerberos configs are not directly related.

> I now verified that you can actually do configure engine-backup to backup whatever you want, and that it always restores everything that it backed up.

https://bugzilla.redhat.com/show_bug.cgi?id=1715767#c3 && /etc/ovirt-engine-backup/engine-backup-config.d/ is an excellent idea esp. if an example is added to the official docs.

This is a very good solution, thank you!

Moving to ON_QA for testing.

Testing flow:
1. Install and setup an engine
2. Configure and run engine-backup to backup /etc/chrony.conf, /etc/ntp.conf, /etc/hosts (see comment 15)
3. Reinstall the machine / use a different one
4. Restore the backup
5. Run engine-setup
6. Check that the relevant files were restored.

Once approved by QE can be moved to doc team.

Tested on ovirt-engine-4.4.0-0.5.master.el7.noarch

I don't see any of the files mentioned in backup archive.
Also the patch linked to this bug is abandoned.

(In reply to Petr Matyáš from comment #18)
> Tested on ovirt-engine-4.4.0-0.5.master.el7.noarch
> 
> I don't see any of the files mentioned in backup archive.

Please see comment 17 and comment 15.

> Also the patch linked to this bug is abandoned.

Indeed. It's a TestOnly bug intended to be handed over to doc team.

Moving to doc team.

With added configuration from comment#15 everything specified there is backed up and can be restored.

let's document comment #15 as example for adding to backup/restore any file admin wants to be backed up and restored.

I'll add a topic to the Admin Guide section on "Adding configuration files to the backup" with the content in comment 15 as an example.

I added an example to the existing topic on using `engine-backup`. Please review. Keep in mind this is low priority.

https://gitlab.cee.redhat.com/rhci-documentation/docs-Red_Hat_Enterprise_Virtualization/-/merge_requests/1956

The name of the topic is: 

Creating a backup with the engine-backup command

Gitlab comment from Didi:

> Looks good to me.

Richard, could you please do a peer review of this topic?

(In reply to Steve Goodman from comment #26)
> Richard, could you please do a peer review of this topic?

Made a couple comments; overall, looks good.

Merged.