Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2008976

Summary: [FFWD 13->16.1] Python 2 packages cleaning up after leapp upgrade failing in leapp dependencies
Product: Red Hat OpenStack Reporter: Jose Luis Franco <jfrancoa>
Component: openstack-tripleo-heat-templatesAssignee: Jose Luis Franco <jfrancoa>
Status: CLOSED ERRATA QA Contact: Jason Grosso <jgrosso>
Severity: high Docs Contact:
Priority: high    
Version: 16.1 (Train)CC: amcleod, gkadam, gregraka, hyunpark, jpretori, lbezdick, mburns, spower
Target Milestone: z7Keywords: Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-11.3.2-1.20210720153313.el8ost Doc Type: Bug Fix
Doc Text:
Before this update, removal of the `python2` packages for the Red Hat Enterprise Linux (RHEL) in-place upgrade tool, LEAPP, was unsuccessful. This failure was caused by a DNF `exclude` option that retained the LEAPP packages. With this update, automation has now been included to ensure that the necessary LEAPP packages are successfully removed.
Story Points: ---
Clone Of:
: 2008981 (view as bug list) Environment:
Last Closed: 2021-12-09 20:20:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2008847    
Bug Blocks: 2008981    

Description Jose Luis Franco 2021-09-29 15:37:17 UTC
Description of problem:

With the release of leapp version 5.0.8-100.202109241452Z.1332835 the FFWD CI jobs from 13 to 16.1 starting failing right after the leapp upgrade step, during the python2-* packages cleaning up:

2021-09-27 11:14:57 | TASK [Clean up Python 2 packages] **********************************************
2021-09-27 11:14:57 | Monday 27 September 2021  11:14:54 +0000 (0:00:07.574)       0:02:07.778 ****** 
2021-09-27 11:14:57 | fatal: [controller-0]: FAILED! => {"changed": false, "failures": [], "msg": "Depsolve Error occured: \n Problem 1: package leapp-deps-el8-5.0.8-100.202109241452Z.1332835.master.el8.noarch requires python2-requests, but none of the providers can be installed\n  - package python2-leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch requires leapp-framework-dependencies = 3, but none of the providers can be installed\n  - conflicting requests\n  - problem with installed package python2-leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch\n Problem 2: package python2-leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch requires leapp-framework-dependencies = 3, but none of the providers can be installed\n  - package leapp-deps-el8-5.0.8-100.202109241452Z.1332835.master.el8.noarch requires python2-setuptools, but none of the providers can be installed\n  - package leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch requires python2-leapp = 0.12.1-100.202109011254Z.8d17bcb.master.el7_9, but none of the providers can be installed\n  - conflicting requests\n  - problem with installed package leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch\n Problem 3: package python2-leapp-0.12.1-100.202109011254Z.8d17bcb.master.el7_9.noarch requires leapp-framework-dependencies = 3, but none of the providers can be installed\n  - package leapp-deps-el8-5.0.8-100.202109241452Z.1332835.master.el8.noarch requires python2-six, but none of the providers can be installed\n  - package leapp-upgrade-el7toel8-0.14.0-100.202109241452Z.1332835.master.el7_9.noarch requires leapp-framework >= 2.0, but none of the providers can be installed\n  - package leapp-upgrade-el7toel8-0.14.0-100.202109241452Z.1332835.master.el7_9.noarch requires leapp-framework < 3, but none of the providers can be installed\n  - package leapp-upgrade-el7toel8-0.14.0-100.202109241452Z.1332835.master.el7_9.noarch requires python2-leapp, but none of the providers can be installed\n  - conflicting requests\n  - problem with installed package leapp-upgrade-el7toel8-0.14.0-100.202109241452Z.1332835.master.el7_9.noarch", "rc": 1, "results": []}
2021-09-27 11:14:57 | 

Logs: http://rhos-ci-logs.lab.eng.tlv2.redhat.com/logs/rcj/DFG-upgrades-ffu-16.1-from-13-latest_cdn-3cont_1comp-ipv4-ovs_lvm/49/undercloud-0/home/stack/overcloud_upgrade_run-controller-0.log.gz

CI job Logs: https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/upgrades/view/ffu/job/DFG-upgrades-ffu-16.1-from-13-latest_cdn-3cont_1comp-ipv4-ovs_lvm/49/

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Jose Luis Franco 2021-09-29 15:43:16 UTC
The source of the problem, as described by Peter in https://bugzilla.redhat.com/show_bug.cgi?id=2008847#c3 comes from the fact of mantaining the leapp packages during the leapp-upgrade. The decision taken was to modify the DNF configuration adding an excludes option with all the leapp packages wanted to be kept: https://github.com/oamg/leapp-repository/commit/abe38e8a75d8188928274763c7abca4c62410449 , as a result, when we try to clean up all the python2 packages some of the dependencies removed force the removal of the leapp-packages, which are part of the excludes DNF config ending up in an error.

The solution is to unset that excludes option from the DNF configuration with the command:

# dnf config-manager --save --setopt exclude=''

Comment 7 Jose Luis Franco 2021-10-04 10:45:41 UTC
There is a possible workaround for those users which have their upgrade planned to 16.1.6 (once the new leapp package will be officially released):

1. Add into UpgradeInitCommand heat parameter the following command:

parameter_defaults:
    UpgradeInitCommand: "dnf config-manager --save --setopt exclude=''"

This will unset the exclusion right after upgrading via leapp and just before starting the python2-* packages cleaning up unblocking the upgrade.

Comment 17 Jose Luis Franco 2021-11-24 16:09:33 UTC
(In reply to Jose Luis Franco from comment #7)
> There is a possible workaround for those users which have their upgrade
> planned to 16.1.6 (once the new leapp package will be officially released):
> 
> 1. Add into UpgradeInitCommand heat parameter the following command:
> 
> parameter_defaults:
>     UpgradeInitCommand: "dnf config-manager --save --setopt exclude=''"
> 
> This will unset the exclusion right after upgrading via leapp and just
> before starting the python2-* packages cleaning up unblocking the upgrade.

Small nit about the workaround. To avoid having a failed task due to non-permitted operation, add sudo in the command:

parameter_defaults:
    UpgradeInitCommand: "sudo dnf config-manager --save --setopt exclude=''"

Comment 25 Greg Rakauskas 2021-12-07 22:11:25 UTC
Hi Jesse,

An RHOSP Doc team script extracts the contents of the "Doc Text" field in this
BZ for use in the RHOSP release notes.

I have edited the "Doc Text" contents to conform to Red Hat style guidelines.
(See below).

Please add a comment to this BZ indicating whether my doc text edits:

   1. are OK, or
   2. require some changes.

If condition (2) is true, then please provide the required changes.

Thanks for your help with this,
--Greg


PROPOSED DOC TEXT EDIT
----------------------
Before this update, removal of the `python2` packages for the Red Hat Enterprise
Linux (RHEL) in-place upgrade tool, LEAPP, was unsuccessful. This failure was
caused by a DNF `exclude` option that retained the LEAPP packages. With this
update, automation has now been included to ensure that the necessary LEAPP
packages are successfully removed.

Comment 31 errata-xmlrpc 2021-12-09 20:20:46 UTC
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 (Red Hat OpenStack Platform 16.1.7 (Train) bug fix and enhancement 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.

https://access.redhat.com/errata/RHBA-2021:3762