Description of problem: Failed to remove life cycle environment from the capsule due to error in the option "--environment-id"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use a specific customer database to perform satellite clone operation.
2. Satellite-clone started successfully.
3. During Lifecycle environment cleanup we get some unknown option error.
Warning: Option --environment-id is deprecated. Use --lifecycle-environment-id instead
Could not remove the lifecycle environment from the capsule:
Error: Option '--environment-id': Numeric value is required..
Life cycle environment dissociation should be completed successfully without any warning or error.
We are using the upstream master branch for satellite cloning.
The issue seems to be with a leftover "/etc/hammer/cli.modules.d/csv.yml" file, which is for the unsupported hammer_cli_csv rpm. This file still marks the hammer module as enabled. The workaround is to remove /etc/hammer/cli.modules.d/csv.yml from config_files.tar.gz in the backup or add a step in sat-clone code to do so.
I can add a step in sat-clone to ensure this file is removed, which should help things, and also make sure that the hammer warnings don't cause errors like this for all commands. I'm not clear if the installer needs any changes. That file is not owned by any packages so it may be left hanging around other installations.
Ewoud, do you think any changes will be needed for the installer?
No, the installer has never been aware of the hammer cli csv plugin. In a normal workflow the /etc/hammer/cli.modules.d/csv.yml file is owned by (tfm-)rubygem-hammer_cli_csv and cleaned up when you yum remove it. Potentially leaving it as .rpmsave. That means it's a problem that sat-clone needs to solve.
> In a normal workflow the /etc/hammer/cli.modules.d/csv.yml file is owned by (tfm-)rubygem-hammer_cli_csv and cleaned up when you yum remove it. Potentially leaving it as .rpmsave.
It doesn't look like this file is owned by the rpm and this is why it is sticking around on upgrades, even after the rpm is removed. I'll add a step to remove it from clone, but iiuc it will still be there on non-cloned systems.
Should the installer ensure that this file is removed to be sure its properly cleaned up?
Are you sure the RPM is actually installed on the system you're testing? https://github.com/theforeman/foreman-packaging/blob/96875ed2cfd5454b304c3db8b2eb7824c8bfd87d/packages/katello/rubygem-hammer_cli_csv/rubygem-hammer_cli_csv.spec#L63 suggests it's owned by the RPM.
It feels odd to let the installer ensure a file is absent while it never installed the plugin. AFAIK it was always pulled in via the satellite-cli meta-package. On a clone, do you install the old (6.5, right?) RPM that actually contains the files or do you install 6.6 straight away?
A sat-clone PR to fix this was merged: https://github.com/RedHatSatellite/satellite-clone/pull/367
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.