[RFE] Migrating a system from RHSM or SAM using the bootstrap script should not require the --force option.

[sideangleside]

Description of problem from bz 1478769

When migrating a system from RHSM or SAM using bootstrap.py, the script will fail as it believes the system is already registered and the underlying subscription-manager command fails. Passing the --force option to bootstrap.py allows the registration to complete, however, this behavior is inconsistent. migrating from RHN/Sat doesn't require --force; migrating from RHSM/SAM does.

Additionally, the --force option was originally intended to allow a user to override the logic that bootstrap.py has to prevent a user from running the script against a system which is already properly registered. Having to use the --force switch for a common registration workflow is counter-intuitive and overloads the meaning of --force

the script fails with an error similar to the following

[NOTIFICATION], [2017-08-03 06:51:26], [Retrieving Client CA Certificate RPMs] 
[RUNNING], [2017-08-03 06:51:26], [rpm -Uvh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm] 
Retrieving http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Preparing...                ##################################################
katello-ca-consumer-satellit##################################################
[SUCCESS], [2017-08-03 06:51:27], [rpm -Uvh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm], completed successfully.

[NOTIFICATION], [2017-08-03 06:51:27], [Writing FQDN katello-fact] 
[NOTIFICATION], [2017-08-03 06:51:27], [Calling subscription-manager] 
[RUNNING], [2017-08-03 06:51:27], [/usr/sbin/subscription-manager register --org 'Example' --name 'sam-client.example.com' --activationkey 'ak_Reg_To_Library_EL6'  --serverurl=https://satellite.example.com:443/rhsm --baseurl=https://satellite.example.com/pulp/repos] 
[ERROR], [2017-08-03 06:51:28], EXITING: [/usr/sbin/subscription-manager register --org 'Example' --name 'sam-client.example.com' --activationkey 'ak_Reg_To_Library_EL6'  --serverurl=https://satellite.example.com:443/rhsm --baseurl=https://satellite.example.com/pulp/repos] failed to execute properly.
This system is already registered. Use --force to override

Expected results:
Register should complete without having to pass --force.

[Rocco83]

I agree that to "fix" a system, --force should not be needed.

But:

What if the script run by error?
Your pull is not human error proof :-)

How to deal with a system to be fully re-registered and re-registered?
In example what if a destination system has to be reinstalled from scratch, losing the current certificates?
What if I have to move the system to another capsule maybe because of data center relocation?

Plus a corner case: is there a way through bootstrap.py to remove only one module (like puppet, or katello), in example to move from katello to Rex?

Maybe --force make sense "as is" as behavior, for sure has to be more robust and avoid DB discrepancies.
What do you think about it?

Hint:
--force to "force migration" is not clearly understandable, --force-migration would be more readable.

My 2 cents,

[sideangleside]

What if the script run by error?
Your pull is not human error proof :-)

If bootstrap is run on a host that is registered to RHN/Sat5 today by error, nothing stops the script from running. My PR just makes that behavior consistent when a system is registered via RHSM or SAM. It is only when the system is registered to a Satellite 6 / Katello instance that we prevent the user from re-running the script. This PR makes the standard workflow (registering/migrating from !(Katello|Satellite) work without --force for all source platforms).

How to deal with a system to be fully re-registered and re-registered?

I am pretty sure the --remove option covers that.

In example what if a destination system has to be reinstalled from scratch, losing the current certificates?

This is a use-case we dont cover at all today. subscription-manager does have the --consumerid option (for example) that allows a system to (re)register to an existing profile. I dont think puppet has an equivalent functionality.

What if I have to move the system to another capsule maybe because of data center relocation?

That's #168 (still WIP) :)

Plus a corner case: is there a way through bootstrap.py to remove only one module (like puppet, or katello), in example to move from katello to Rex?

No. But I think that is beyond the scope of what bootstrap.py should do. Registering, migrating and other 'day 1' tasks are within scope. Changing the running configuration of a properly running system is IMHO out of scope.

Maybe --force make sense "as is" as behavior, for sure has to be more robust and avoid DB discrepancies.
What do you think about it?
Hint:
--force to "force migration" is not clearly understandable, --force-migration would be more readable.

--force disables our 'idiot-proofing', allowing the user to migrate from katello -> katello. AND it disables our domain name checking that we do to ensure your FQDN is sane. So renaming it to --force-migration would be accurate for only one of those usages.

[Rocco83]

If bootstrap is run on a host that is registered to RHN/Sat5 today by error, nothing stops the script from running. My PR just makes that behavior consistent when a system is registered via RHSM or SAM. It is only when the system is registered to a Satellite 6 / Katello instance that we prevent the user from re-running the script. This PR makes the standard workflow (registering/migrating from !(Katello|Satellite) work without --force for all source platforms).

Got it.
Opening PR for the other stuff :)