SUSE migration services pre-check for lingering `smt-ec2.susecloud.net` /etc/hosts entries

[thimslugga]

The SUSE migration services pre-checks should check for lingering smt-ec2.susecloud.net entries in the /etc/hosts file, where the host is actually connected directly to the SCC and using updates.suse.com. It should warn for these lingering /etc/hosts entries as they can cause issues during SUSE dist migration activities.

[schaefi]

I do not understand the negative impact for the DMS if the connection to the SUSE repositories is established via the public cloud infrastructure (RMT proxy) or a direct connection to SCC or any other form of proxy connection ? Is it a responsibility of the DMS pre-checks to guess on the connectivity setup ? Unless there is a direct coupling between code in DMS and the way how to connect to the suse update server(s) we should not add a pre-check.

The DMS connects to suse repos in two ways:

1. via zypper dup and locally configured repositories. A zypper refresh prior starting the DMS is suitable to detect any connection issues
2. via the zypper migration plugin. I'm not aware that the API call to the SCC backend differentiates if the call is made to SCC or a proxy.

From that perspective if you believe we need a check, can you be more specific on what "can cause issues" mean ?

Thanks

[rjschwei]

During migration everything is driven by the information that is in the RIS files. The only issue I could see with a system that was once connected to the update infrastructure and then switched to point to SCC is that a specific RIS file, a file in /etc/zypp/services.d points to the update infrastructure while other files point to updates.suse.com. If that is the case then that would be a bug in registercloudguest --clean.
What we can check, as a pre-check, is that there is no mix between *.susecloud.net and updates.suse.com in the files contained in /etc/zypp/services.d. Meaning, for example the service for the Basemodule points to susecloud.net and for the Public-Cloud-Module points to updates.suse.com, such an inconsistent setup would definitely create problems.

[thimslugga]

@rjschwei, related SUSE/connect-ng#242

@schaefi, A lingering smt-ec2.susecloud.net hosts entry that wasn't cleaned up, where the customer has switched to updates.suse.com will result in attempts to dist upgrade via DMS to fail.

[schaefi]

What we can check, as a pre-check, is that there is no mix between *.susecloud.net and updates.suse.com in the files contained in /etc/zypp/services.d

Thanks much for the details, yes that makes sense and could be pre-checked

[jirib]

Shouldn't we ignore commented out lines -

suse-migration-services/suse_migration_services/units/prepare.py

Line 138 in f953990

if 'susecloud.net' in contents:

? IIUC the code considers all lines.

[rjschwei]

@rjschwei, related SUSE/connect-ng#242

@schaefi, A lingering smt-ec2.susecloud.net hosts entry that wasn't cleaned up, where the customer has switched to updates.suse.com will result in attempts to dist upgrade via DMS to fail.

This cannot be. What is in /etc/hosts is only used for host name resolution. If the system is properly registered to SCC then there is no need for the resolution of anything related to the update infrastructure and an entry in /etc/hosts that refers to anything susecloud.net is simply superfluous.

[rjschwei]

Shouldn't we ignore commented out lines -

suse-migration-services/suse_migration_services/units/prepare.py

Line 138 in f953990

if 'susecloud.net' in contents:
? IIUC the code considers all lines.

Again looking for an entry in /etc/hosts is barking up the wrong tree. If there is an issue then the inconsistency exists somewhere else.