Bug 2219844

Summary: leapp is sometimes in our way when doing a FFU from 13 -> 16.2
Product: Red Hat OpenStack Reporter: David Hill <dhill>
Component: openstack-tripleo-heat-templatesAssignee: Sergii Golovatiuk <sgolovat>
Status: CLOSED DUPLICATE QA Contact: Joe H. Rahme <jhakimra>
Severity: low Docs Contact:
Priority: medium    
Version: 16.2 (Train)CC: jbadiapa, jpretori, mburns
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-19 18:05:04 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:

Description David Hill 2023-07-05 15:06:04 UTC
Description of problem:
leapp is sometimes in our way when doing a FFU from 13 -> 16.2 .   In this case, it looks like we should have an exclusion before running distro-sync or leapp should be removed ...   I wrote [1] with an exclusion first and after consideration, leapp is no longer needed so it's safe to make sure it's absent , isn't it ?

[1] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/887716
Version-Release number of selected component (if applicable):


How reproducible:
This one

Steps to Reproduce:
1. don't know yet
2.
3.

Actual results:
[root@controller ~]# dnf -y distro-sync
Updating Subscription Management repositories.
Last metadata expiration check: 0:05:39 ago on Wed 05 Jul 2023 06:08:20 PM +08.
Error:
 Problem 1: package leapp-0.15.0-1.el8_4.0.3.noarch requires python3-leapp = 0.15.0-1.el8_4.0.3, but none of the providers can be installed
  - package python2-leapp-0.15.1-1.el7_9.noarch conflicts with python3-leapp provided by python3-leapp-0.15.0-1.el8_4.0.3.noarch
  - package python3-leapp-0.15.0-1.el8_4.0.3.noarch conflicts with python2-leapp provided by python2-leapp-0.15.1-1.el7_9.noarch
  - cannot install the best update candidate for package leapp-0.15.1-1.el7_9.noarch
  - problem with installed package python2-leapp-0.15.1-1.el7_9.noarch
 Problem 2: package leapp-0.15.0-1.el8_4.0.3.noarch requires python3-leapp = 0.15.0-1.el8_4.0.3, but none of the providers can be installed
  - package python2-leapp-0.15.1-1.el7_9.noarch conflicts with python3-leapp provided by python3-leapp-0.15.0-1.el8_4.0.3.noarch
  - package python3-leapp-0.15.0-1.el8_4.0.3.noarch conflicts with python2-leapp provided by python2-leapp-0.15.1-1.el7_9.noarch
  - package leapp-upgrade-el7toel8-0.18.0-3.el7_9.noarch requires leapp, but none of the providers can be installed
  - package leapp-upgrade-el7toel8-0.18.0-3.el7_9.noarch requires python2-leapp, but none of the providers can be installed
  - leapp-0.15.1-1.el7_9.noarch does not belong to a distupgrade repository
  - problem with installed package leapp-upgrade-el7toel8-0.18.0-3.el7_9.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@controller ~]#


We got the same issue while upgrading the undercloud and  I opened a case for it (03545221). Redhat support incorrectly pointed out that this was fixed in "openstack-tripleo-heat-templates-11.5.1-2.20210603174826.el8ost.10". (how would a fix in tripleo-heat-templates fix an issue with the undercloud upgrade where we are supposed to run dnf distro-sync manually??). However we were able to successfully proceed with the undercloud  upgrade after including the --allowerasing flag to the dnf distro-sync command as suggested in the same case.

Expected results:


Additional info:

Comment 1 David Hill 2023-07-05 15:22:03 UTC
Probably a follow up of https://bugzilla.redhat.com/show_bug.cgi?id=2008981

Comment 2 David Hill 2023-07-05 20:42:53 UTC
Same as:
https://bugzilla.redhat.com/show_bug.cgi?id=2123291

Comment 3 Sergii Golovatiuk 2023-07-19 18:05:04 UTC

*** This bug has been marked as a duplicate of bug 2123291 ***