Max Gautier

/retest-failed

> @VannTen, could you take a look at the package installation? `kernel-modules-extra` needs to align with the OS kernel version, I'm not sure `system_package` can use a dynamic package name...

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_monitoring_and_updating_the_kernel/index The docs does not seem to expect administrators to specify a version, AFAICT.

Hum. And I guess if we don't upgrade the kernel stay at whatever versions it was and thus we get a mismatch. (like: ``` package: name: '*' state: latest ```...

I also don't think that something like this is possible (to upgrade the existing **and** install new packages) : ```yaml package: name: - package1 - package2 - '*' state: latest...

The approach is #12513 (upgrade to latest + reboot on kernel-*) upgrade appear to work. That's kinda invasive, though. I'm not sure what we should do, because `ansible_kernel` is a...

Maybe something like: Gate "upgrade all" behind a bool variable, default to "ansible_os_family == RedHat && ansible_distribution_major_version == '10'" same thing for reboot. After 2.29, default to `true` unconditionally ?...

I'd rather keep install and upgrade as close as possible (and close the gap, in fact). > For that reason, if Kubespray does start to take care of that aspect...

Special casing in CI to preinstall the version matching the kernel in our test image ? I'm not sure what the best solution is, honestly.

> I would not enter in the teritory of rebooting and deep node administration. We're already there for some stuff, see `roles/upgrade/system-upgrade/tasks/{apt,yum}.yml`