Introduce experimental live mode [squashfs]

[MichalHe]

This work is based on @bessonc's (cbesson) awesome livemode actors.

Description

This patch introduces a feature named live mode allowing to boot into a squashfs of the target userspace, reaching the target multi-user. Therefore, it is possible to interact with the upgrade environment while the upgrade is running in the background, or, debug crash of the service while having a fully booted system (although the system is relatively minimal). Reaching multi-user means that the environment could have network available, and the patch will set up network configurations for target userspace, however, it is a best-effort solution at the moment. The patch somehow simplifies development of such features, as one can boot into the squashfs, log in, check whether everything is as expected and if not the developer can manually play with the system recording his/hers modifications. Later, the developer just needs to reproduce these modifications in the code.

If the feature is not used/enabled, then leapp's behavior remains unchanged, although this patch refactors some of leapp's core actors (e.g., add_upgrade_boot_entry).

How to run:

Note that one needs to have squashfs-tools installed. Moreover, the feature is currently limited to x86_64 only and attempting to run it on a different architecture will be prevented by leapp.

LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_ENABLE_LIVE_MODE=1 leapp upgrade --debug \
    --whitelist-experimental='live_image_generator' \
    --whitelist-experimental='live_mode_config_scanner' \
    --whitelist-experimental='live_mode_reporter' \
    --whitelist-experimental='prepare_live_image' \
    --whitelist-experimental='emit_livemode_requirements' \
    --whitelist-experimental='remove_live_image'

Tests coverage:

• add_upgrade_boot_entry
• live_image_generator
• live_mode_config
• live_mode_report
• prepare_live_image
• emit_livemode_userspace_requirements

Jira ref: RHEL-45280

[abadger]

I reviewed the whole PR yesterday and it looks great. The approach looks good and I didn't find anything that looks like it will introduce a bug. Everything I noted is a small thing and can be deferred until a later PR. I did find that my spotting of little things that could be changed went down in the second half of the PR, though, so it's possible I've missed things. I've asked @MichalHe to point out the places that I should take a harder look at (because those places will run when we are not in livemode) and I will take a second look at those.

[pirat89]

the shell script does not reflect some recent upstream changes requested by support. e.g. this should not block the upgrade (even when it will most likely lead to crash later). As this is experimental only, it's not a problem, but we should reflect the changes at least in a follow up PR

[pirat89]

/packit copr-build

[Rezney]

/packit copr-build

[Rezney]

Great job! Once the last failing "unittest" is fixed we are ready to go.

[pirat89]

I am trying to get the tests fixed. There are 2 problems

• broken building for rhel 7 in copr due to rhel 7 EOL kind of (so we ignore that one)
• broken test for leapp data files which hasn't expected that the leapp-upgrade-elXtoelY rpm could contain additional configuration files

I've already created a MR for the problematic test. let's see if we will be able to proceed in few hours.

[pirat89]

/packit copr-build

[pirat89]

in future, we should check the available memory and raise this output just in case we see that there is not enough memory avilable. Note that information about total memory is covered by MemoryInfo msg, but I do not remember now whether it's physical only or whether it includes swap as well - note that in some cases we should not count with SWAP.

[pirat89]

Passed! Reviewed most of the code (I haven't reviewed deeply some experimental actors). It seems the solution works as expected. Additional changes are expected to be delivered in another PRs in future.

Great job guys!!! 🚀