Support pre-checks also for the run_migration method

[schaefi]

Problem Description

If customer decides to go with the real reboot mode, the package suse-migration-sle15-activation gets installed and the pre-checks runs as part of %post. So all good in this case.

If the customer decides to go with run_migration, no activation package will be installed because run-migration is provided with the package that contains the migration live image (SLE15-Migration). In this case no pre-checks are available

If the customer installs suse-migration-sle15-activation for the reason to get the pre-checks, there will also be the grub menu entry which is unwanted but does not hurt.

For the moment we could add some information in the documentation that says to run the pre-checks, install the activation package. No matter how the migration is started, the activation and also migration packages will be uninstalled by the migration code itself (except this stage is not reached by the DMS). However, this feels not natural to install an activation package for running pre-checks, so feels more like a workaround

Another option would be to split the suse-migration-sle15-activation package into two packages:

• suse-migration-sle15-activation
• suse-migration-sle15-pre-checks

The activation package would require the pre-checks, such that %post works. Customers using run_migration can install only the pre-checks package and manually call them. This needs to be documented. And a new pre-checks package must be published through the SUSE process

[schaefi]

DMS - SUMA Integration

[KeithMnemonic]

@rjschwei I need to implement this so we can also add additional prechecks. Are you ok with the new package name being suse-migration-sle15-pre-checks as per the suggestion from Marcus. If not, please provide a name.

[KeithMnemonic]

actually, I am not sure we need to split the package based on this https://github.com/SUSE/suse-migration-services/blob/master/package/suse-migration-services-spec-template#L57 cant we simply add this back in and be all set? Any thoughts @jesusbv ?

[schaefi]

@KeithMnemonic Hi, the reason why I suggested to split the package is to distinguish in a clean way between pre-checks and the setup to activate for migration. It's not required that you split and you can just keep the packaging layout.

However, as explained if you use the run_migration method which starts the migration using kexec and no bootloader settings are needed, you don't need an activation package. As long as the activation package provides the pre-checks you will lack pre-checks when starting via run_migration.

I leave it up to you if you would like to cleanup this situation, I would do it as it makes it more clear what package provides what and has what functionality

[KeithMnemonic]

@schaefi This is confusing though. The spec file [1] for suse-migration-services, has the following

# suse-migration-pre-checks is relevant for the activation package only
rm -f %{buildroot}/%{_bindir}/suse-migration-pre-checks

So if this issue is now saying that prechecks are actually "relevant" , why not just re-enable it here? Since suse-migration-sle15-activation requires SLES15-Migration (which includes suse-migration-services ), it would just get run during that install.

Also, it seems looking at the code, the only time pre-check is run is during the install of suse-migration-sle15-activation. This would mean it is not run after reboot anyway. Am I missing something here?

[1] https://github.com/SUSE/suse-migration-services/blob/master/package/suse-migration-services-spec-template#L57-L58

[KeithMnemonic]

I think I get it know, let me hash on this some more

[rjschwei]

Yes I think the package split makes sense. Then both suse-migration-services and suse-migration-sle15-activation can have a Requires: suse-migration-pre-checks. Note I dropped the version indicator. I don't think the pre-checks are/will be dependednt on the distribution version.

[KeithMnemonic]

@rjschwei Thank you for the feedback. I have a draft PR up but I still have a few loose ends and also need to update the docs. Is it your opinion that the install order be

SLES15-Migration suse-migration-pre-checks suse-migration-sle15-activation

with each successor having the prior as a "Requires". Should perhaps the pre-checks come before SLES15-Migration?

[KeithMnemonic]

@rjschwei perhaps the best solution is to make the SLES15-Migration be dependant on suse-migration-pre-checks. This way a customer can resolve any issues before installing SLES15-Migration?

[rjschwei]

@KeithMnemonic yes, as stated

Then both suse-migration-services and suse-migration-sle15-activation can have a Requires: suse-migration-pre-checks.

If suse-migration-services has the Requires: then the ISO build, i.e. SLES15-Migration will automatically get the pre-checks. I am not certain how useful it is to have the wrapper, i.e. SLES15-Migration have a dependency on the pre-checks. That would mean we add an additional manual step, i.e. "Dear user run the pre-checks first" to a process that we want to be a little touch as possible. Additionally the pre-checks will run twice as they need to be integrated with suse-migration-services. As such I think it will make for a smoother user experience if we run the pre-checks as part of the migration and don't ask the user to do so manually as well.