feat: Add leapp_pre_upgrade_update variable to the analysis role by spetrosi · Pull Request #383 · redhat-cop/infra.leapp

spetrosi · 2026-03-18T11:20:23Z

The analysis role historically runs only the pre-upgrade analysis that does not do any changes to the system.
However, in the case where the target system is not fully-updated - the analysis might pass, but the dnf update that the upgrade role does might bring some new inhibitors, hence the upgrade might fail. So, the proper approach would be to allow the analysis role do the required pre-upgrade steps so that the analysis is run on the same system as the upgrade.

When leapp_pre_upgrade_update: true is set, the analysis role will do the following:

Clear the versionlock list
Update all packages
Reboot if any packages were updated.

spetrosi · 2026-03-18T11:41:39Z

[citest]

spetrosi · 2026-03-18T12:57:01Z

[citest]

richm · 2026-03-18T13:13:13Z

roles/analysis/defaults/main.yml

 # Directory to store leapp pre-upgrade reports and remediation hostvars
 leapp_workdir_controller: "{{ playbook_dir }}"
+
+# Whether to update all packages to latest version before running leapp analysis


and reboot if needed?

Fixed. I am not a fun of duplicating vars description in readme and here

spetrosi · 2026-03-18T13:17:20Z

[citest]

spetrosi · 2026-03-18T13:38:35Z

Waiting for @swapdisk and @djdanielsson opinions.

This changes the default behavior of the analysis role - it now clears versionlock list, updates all packages and reboots.

djdanielsson · 2026-03-18T13:55:20Z

analysis shouldn't update/touch anything that should be remediation. the most analysis should do is install leapp and run it IMO. a lot of times we tried to push because it is just doing analysis it would be safe to run anytime and not require maintenance window. @swapdisk thoughts?

swapdisk · 2026-03-18T14:32:08Z

I agree with @djdanielsson.

Having big changes and reboots possible in the analysis role would qualify as a "breaking change" to the collection. Making "no impactful changes" during the analysis phase is a key part of the narrative when we talk about the end-to-end workflow of RHEL upgrade automation.

However, another key point we talk about is not making changes between when you run the analysis and when you launch the upgrade. The upgrade role doing dnf update before starting the upgrade kind of breaks that rule. That is the crux of the problem here.

I think the best way to solve this would be make the analysis job fail or raise an inhibitor when a host is so far behind on updates that it will lead to this issue. Then updating such a host can be treated as a required remediation just like any other inhibitor. That way, we're keeping with our existing end-to-end approach that everybody has gotten comfortable with.

swapdisk

As I mentioned in the main comment thread, I would prefer a fail or inhibitor rather than allowing changes during analysis.

But if we do decide to go with this, I would at least like to make sure we fix the "pre-upgrade" terminology and make the new var default to false.

swapdisk · 2026-03-18T14:58:19Z

changelogs/fragments/383-analysis-pre-upgrade.yml

+  - The analysis role historically runs only the pre-upgrade analysis that does not do any changes to the system.
+  - However, in the case where the target system is not fully-updated - the analysis might pass, but the dnf update that the upgrade role does might bring some new inhibitors, hence the upgrade might fail.
+  - So, the proper approach would be to allow the analysis role do the required pre-upgrade steps so that the analysis is run on the same system as the upgrade.


We need to be careful how we use the pre-upgrade wording. Historically, the term pre-upgrade has mostly been synonymous with analysis. Like we might say "The analysis phase generates the pre-upgrade report," for example.

However, "required pre-upgrade steps" here means "changes required before generating the report" which is very different.

The same goes for the leapp_pre_upgrade var name, as I commented below in more detail.

The concept here is "prepare the system so that the analysis is as accurate as possible, so that we find all of the inhibitors/issues during analysis, so that we don't run upgrade only to find there were inhibitors/issues missed during analysis" - is there a terse way we can describe that concept?

swapdisk · 2026-03-18T15:07:20Z

roles/analysis/defaults/main.yml

 leapp_workdir_controller: "{{ playbook_dir }}"
+
+# Whether to update all packages to latest version and reboot before running leapp analysis
+leapp_pre_upgrade: true


To avoid any possible confusion with the meaning of pre-upgrade as in "generating the pre-upgrade report" as documented for the leapp preupgrade command, let's change this variable name. I think the leapp_update_all_packages name in the title of the PR would be fine.

Also, unless we want to put this forward as an API breaking change for a version 2.0.0, it should be false by default.

I was thinking that we can add more automated pre-upgrade tasks in the future. Like e.g. doing a backup etc.

How about pre-analysis?

swapdisk · 2026-03-18T15:12:36Z

roles/analysis/README.md

+| Name                      | Type   | Default value | Description |
+|---------------------------|--------|---------------|-------------|
+| leapp_upgrade_type        | String | "cdn"         | Set to "cdn" for hosts registered with Red Hat CDN, "rhui" for hosts using rhui repos, "satellite" for hosts registered to Satellite, and "custom" for custom repos. |
+| leapp_pre_upgrade         | bool   | true          | Prepare for the upgrade. When true, the role will do the following - clear the versionlock list, update all packages and optionally reboot if any packages were updated. |


As mentioned above, change the var name and default to false.

swapdisk · 2026-03-18T15:12:57Z

roles/analysis/README.md

+
+
+
+leapp_pre_upgrade: true


The analysis role historically runs only the pre-upgrade analysis that does not do any changes to the system. However, in the case where the target system is not fully-updated - the analysis might pass, but the `dnf update` that the upgrade role does might bring some new inhibitors, hence the upgrade might fail. So, the proper approach would be to allow the analysis role do the required pre-upgrade steps so that the analysis is run on the same system as the upgrade. When `leapp_pre_upgrade: true` is set, the analysis role will do the following: 1. Clear the versionlock list 2. Update all packages 3. Reboot if any packages were updated.

roles/upgrade/README.md

spetrosi · 2026-03-19T14:24:36Z

[citest]

spetrosi · 2026-03-19T14:29:54Z

[citest]

spetrosi · 2026-03-19T15:09:22Z

[citest]

spetrosi force-pushed the pre-upgrade-to-analysis branch 2 times, most recently from 1437ec4 to ada466f Compare March 18, 2026 11:39

spetrosi force-pushed the pre-upgrade-to-analysis branch from ada466f to 96d2d89 Compare March 18, 2026 12:56

richm reviewed Mar 18, 2026

View reviewed changes

spetrosi force-pushed the pre-upgrade-to-analysis branch from 96d2d89 to 030d856 Compare March 18, 2026 13:17

spetrosi mentioned this pull request Mar 18, 2026

fix: Rebuild initramfs when module config changed #382

Merged

spetrosi marked this pull request as draft March 18, 2026 13:38

swapdisk reviewed Mar 18, 2026

View reviewed changes

spetrosi force-pushed the pre-upgrade-to-analysis branch from 030d856 to 5b505e3 Compare March 19, 2026 12:11

spetrosi commented Mar 19, 2026

View reviewed changes

roles/upgrade/README.md Show resolved Hide resolved

spetrosi force-pushed the pre-upgrade-to-analysis branch 3 times, most recently from 81d97cd to 19de2e0 Compare March 19, 2026 14:10

spetrosi requested a review from swapdisk March 19, 2026 14:24

spetrosi force-pushed the pre-upgrade-to-analysis branch from 19de2e0 to 3425946 Compare March 19, 2026 14:26

spetrosi marked this pull request as ready for review March 19, 2026 14:37

Rename leapp_pre_upgrade to leapp_pre_upgrade_update

bef8d4a

spetrosi force-pushed the pre-upgrade-to-analysis branch from 3425946 to bef8d4a Compare March 19, 2026 15:09

spetrosi changed the title ~~feat: Add leapp_update_all_packages variable for the analysis role~~ feat: Add leapp_pre_upgrade_update variable to the analysis role Mar 20, 2026

spetrosi requested a review from PeterMocary March 20, 2026 10:36

spetrosi requested a review from richm March 20, 2026 10:36

richm approved these changes Mar 20, 2026

View reviewed changes

spetrosi merged commit eea6c8e into redhat-cop:main Mar 20, 2026
29 checks passed




		leapp_pre_upgrade: true

Conversation

spetrosi commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spetrosi commented Mar 18, 2026

Uh oh!

spetrosi commented Mar 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spetrosi commented Mar 18, 2026

Uh oh!

spetrosi commented Mar 18, 2026

Uh oh!

djdanielsson commented Mar 18, 2026

Uh oh!

swapdisk commented Mar 18, 2026

Uh oh!

swapdisk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

spetrosi commented Mar 19, 2026

Uh oh!

spetrosi commented Mar 19, 2026

Uh oh!

spetrosi commented Mar 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

spetrosi commented Mar 18, 2026 •

edited

Loading