dracut modules: add breakpoints with more consistent names

[pirat89]

I've already realized I missed couple of breakpoints over time inside the initramfs and cannot remember expected cmdline params for each of them. So let's try to make it more consistent. Keeping the original cmdline arguments as some people are used to them already, but introducing new ones.

New introduced breakpoints:

• rd.upgrade.break=leapp-initram
  • breaks right after getting to leapp dracut modules
  • orig
    • rd.break=upgrade
    • rd.upgrade.break=upgrade
• rd.upgrade.break=leapp-pre-upgrade
  • breaks just right before running leapp in initramfs
• rd.upgrade.break=leapp-post-upgrade
  • running just right after leapp upgrade (dnf transaction done), before the start of post-upgrade phases
  • orig:
    • rd.break=leapp-upgrade
    • rd.upgrade.break=leapp-upgrade
• rd.upgrade.break=leapp-finish
  • the last breakpoint, after logs are saved, before the upcoming reboot (leaving the upgrade environment)
  • orig:
    • rd.break=leapp-logs

Note: we could possibly drop old ones already, but as this is going to be one of last changes for IPU 7 -> 8, I decided to leave such a decision for future. Also, it's possible that we will need to redesign this part of the upgrade process, so that's another reason why to just add something, but do not drop anything.

TODO

• Improve the messages - adding eg. hint what to do in particular breakpoints, so it's visible in the msg. e.g. run leapp using cmd: ....., etc
• part of the msg could/should be info about deprecated values (when deprecated argument is used, inform about the new value, etc). also we should cover it in upstream documentation

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please @oamg/developers to notify leapp developers of the review request
• /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use /packit test oamg/leapp#42

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

• /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
• /packit test --labels beaker-minimal-8.9to9.3,kernel-rt-8.9to9.3 to schedule kernel-rt and beaker-minimal test sets for 8.9->9.3 upgrade path

[Deprecated] To launch on-demand regression testing public members of oamg organization can leave the following comment:

• /rerun to schedule basic regression tests using this pr build and latest upstream leapp build as artifacts
• /rerun 42 to schedule basic regression tests using this pr build and leapp*PR42* as artifacts
• /rerun-sst to schedule sst tests using this pr build and latest upstream leapp build as artifacts
• /rerun-sst 42 to schedule sst tests using this pr build and leapp*PR42* as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

[pirat89]

@oamg/developers @oamg/qe any ideas? I definitely do not want to drop any previous arguments now (see the description), but happy to hear your opinion about new added arguments.

[pirat89]

let's see whether I will have a time to add the improved messages, etc, as I planned. If not, I would prefer to merge it with the current messages, to have unified break points in the upgrade initramfs across RHEL 7+ systems to make our lives easier.

[matejmatuska]

@oamg/developers @oamg/qe any ideas? I definitely do not want to drop any previous arguments now (see the description), but happy to hear your opinion about new added arguments.

Maybe we could drop either "leapp" from the names of breakpoints or "upgrade" from rd.upgrade.break? It seems a little redundant and is more verbose, however I wouldn't mind leaving the names as they are.

I agree with not dropping the old names.

[pirat89]

@matejmatuska good point. I will think about it. dropping that, it sounds a weird to me than, as we are using terms as post-upgrade, etc.. for a time. and I do not want to end just with "rd.break=..." parameter. but I agree the current proposal seems a little bit redundant. I will think about that when I recover.

[abadger]

I agree that it is redundant but we can change it later.

I think keeping rd.upgrade.break and trying to modify the leapp-* portion is probably the better strategy to explore in the future.

Approving.