Katello / katello-client-bootstrap

Bootstrap Script for migrating systems to Foreman & Katello
GNU General Public License v2.0
52 stars 63 forks source link

Allow bootstrap.py to optionally ignore subscription-manager error when there are no subscriptions allocated. #260

Closed sthirugn closed 6 years ago

sthirugn commented 6 years ago

There are scenarios in which it is okay for the user to register a client to satellite without having a subscription allocated to it. Right now, bootstrap.py fails and exits since it uses exec_failexit on subscription-manager register call as shown below.

def register_systems(org_name, activationkey):
    """
    Register the host to Satellite 6's organization using
    `subscription-manager` and the given activation key.
    Option "--force" is given further.
    """
    ...
    ...
    ...
    exec_failexit("/usr/sbin/subscription-manager register --org '%s' --name '%s' --activationkey '%s' %s" % (org_label, FQDN, activationkey, options.smargs))

the above-mentioned line should use exec_failok if the user wants to optionally ignore non-availability of subscriptions in certain scenarios.

sideangleside commented 6 years ago

The general concern that I have is that by changing to exec_failok is that it would mask other legitimate subscription-manager issues.

This is related to bz1591315. Even when that bug is addressed, we'd still have crusty old versions of subscription-manager in the wild that won't return proper exit codes when registering.

As much as I don't want 'yet another bootstrap.py CLI option', I would rather that in lieu of potentially masking errors in subscription-manager. Registering to a system with org_environment entitlement mode is extremely uncommon. So changing the common case to support the exception seems wrong. Maybe something like --ignore-registration-failures as a boolean.

Also, we'd have to patch the migrate_systems function to handle the migration (from Sat5|Spacewalk|RHN) use-cases.

@evgeni thoughts?

evgeni commented 6 years ago

Yeah, silent failok will be a source for nightmares (but then again, not mine).

--ignore-registration-failures would be a solution -- until someone asks for --ignore-puppet-failures etc?

the other day, I suggested failok with a post-failure check if the failure was legit. but this makes code more complicated, so ugh.

for simplicitys sake, +1 on --ignore

sthirugn commented 6 years ago

+1 to --ignore-registration-failures with a clear help message that it is user responsibility to take care of it.