Perform health check before restore

[maximiliankolb]

users should not (try to) restore to a Foreman/Katello instance that is not running smoothly.

• I am familiar with the contributing guidelines.

Please cherry-pick my commits into:

• Foreman 3.11/Katello 4.13
• Foreman 3.10/Katello 4.12
• Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8)

[github-actions]

The PR preview for f3e7e07 is available at theforeman-foreman-documentation-preview-pr-3066.surge.sh

The following output files are affected by this PR:

• Administering_Project/index-foreman-deb.html
• Administering_Project/index-foreman-el.html
• Administering_Project/index-katello.html
• Administering_Project/index-orcharhino.html
• Administering_Project/index-satellite.html

show diff

show diff as HTML

[evgeni]

Honest question: why not? Things are going to be wiped anyway.

[maximiliankolb]

Honest question: why not? Things are going to be wiped anyway.

I had a user report that things "did not go according to plan" when they tried to restore their backup on an already broken/not running smoothly Foreman/Katello instance. Therefore, I suggest that they perform a health check before restoring from backup.

[ekohl]

I share @evgeni's concerns. Today's installation may be broken, but the restore may fix that. Also, if it fails, what action does the user have?

[evgeni]

I think it's a bit of a mixed bag.
If you broke your install by dropping a db or deleting var lib pulp, health check will be unhappy but restore will work fine (and is expected to, IMHO). But there are certainly ways to break a system where a plain restore won't work and will require a clean system to continue.

[maximiliankolb]

Fair point. Is there any resource to know "how much" your instance can be broken and you'll still be able to fix it by restoring a backup?

Maybe a health check is too rigid, but maybe you expect at least a function "foreman-maintain" and/or "foreman-installer"?

[ekohl]

Often the only way to know that is to run it. We usually don't have a good way to detect why something is broken.

[evgeni]

I don't think we have that, no

[maximiliankolb]

I am unsure if the current docs make sense:

• there is a requirement to "choose the appropriate X.Y version"
• we tell the user to "installing Foreman/Katello" as part of the procedure

Do we support restoring from backup on a used/slightly broken F+K instance? Or is it officially only supported to restore from backup on a freshly installed F+K instance?

Do you have any suggestions @apinnick ?

[apinnick]

I am unsure if the current docs make sense:

* there is a requirement to "choose the appropriate X.Y version"

* we tell the user to "installing Foreman/Katello" as part of the procedure

Do we support restoring from backup on a used/slightly broken F+K instance? Or is it officially only supported to restore from backup on a freshly installed F+K instance?

Do you have any suggestions @apinnick ?

@maximiliankolb Sorry, but I cannot comment on this. I do not know enough about the health check or restore process.

[evgeni]

@maximiliankolb do you have any more insight what the user meant by "did not go according to plan"? If they know what was broken, we could add checks for that, but generally speaking we (as in the team who maintains the backup/restore tooling) expect a "dirty" machine to be sufficient for a restore