Bug 2155305

Summary: [RFE] leapp does not enable non-default modules required for upgrade
Product: Red Hat Enterprise Linux 7 Reporter: jcastran
Component: leapp-repositoryAssignee: Leapp Notifications Bot <leapp-notifications-bot>
Status: NEW --- QA Contact: upgrades-and-conversions
Severity: low Docs Contact:
Priority: low    
Version: 7.9CC: amepatil, fperalta, leapp-notifications, pm-rhel, pstodulk
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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 jcastran 2022-12-20 17:28:06 UTC
Description of problem:
When a package requires a dependency from a non-default stream, leapp fails with:

============================================================
                           ERRORS
============================================================

2022-12-20 12:16:56.611794 [ERROR] Actor: dnf_transaction_check
Message: DNF execution failed with non zero exit code.
STDOUT:
Last metadata expiration check: 0:02:36 ago on Tue Dec 20 12:14:04 2022.

STDERR:
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel-testing.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel-testing.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel-testing.repo; Configuration: OptionBinding with id "failovermethod" does not exist
The following modules were requested to be enabled, but they are unavailable: ADVANCED-VIRT:latest
Warning: Package marked by Leapp to install not found in repositories metadata: python3-nss glassfish-jaxb-api-javadoc glassfish-jaxb-codemodel-annotation-compiler python3-javapackages glassfish-jaxb-rngom stax-ex-javadoc glassfish-jaxb-codemodel ivy-local glassfish-fastinfoset-javadoc glassfish-jaxb-txw2 xsom-javadoc glassfish-jaxb-core glassfish-jaxb-runtime
Warning: Package marked by Leapp to upgrade not found in repositories metadata: gpg-pubkey leapp leapp-upgrade-el7toel8 python2-leapp
Transaction check:

 Problem 1: package glassfish-jaxb-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(org.apache.maven.plugins:maven-enforcer-plugin), but none of the providers can be installed
  - conflicting requests
  - package maven-enforcer-plugin-1.4.1-8.module+el8+2598+06babf2e.noarch is filtered out by modular filtering
 Problem 2: package glassfish-jaxb-codemodel-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(com.sun.xml.bind.mvn:jaxb-parent:pom:) = 2.2.11, but none of the providers can be installed
  - package glassfish-jaxb-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(org.apache.maven.plugins:maven-enforcer-plugin), but none of the providers can be installed
  - conflicting requests
  - package maven-enforcer-plugin-1.4.1-8.module+el8+2598+06babf2e.noarch is filtered out by modular filtering
 Problem 3: package glassfish-jaxb-runtime-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(com.sun.xml.bind.mvn:jaxb-parent:pom:) = 2.2.11, but none of the providers can be installed
  - package glassfish-jaxb-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(org.apache.maven.plugins:maven-enforcer-plugin), but none of the providers can be installed
  - conflicting requests
  - package maven-enforcer-plugin-1.4.1-8.module+el8+2598+06babf2e.noarch is filtered out by modular filtering
 Problem 4: package glassfish-jaxb-external-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(com.sun.xml.bind.mvn:jaxb-parent:pom:) = 2.2.11, but none of the providers can be installed
  - package glassfish-jaxb-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(org.apache.maven.plugins:maven-enforcer-plugin), but none of the providers can be installed
  - conflicting requests
  - package maven-enforcer-plugin-1.4.1-8.module+el8+2598+06babf2e.noarch is filtered out by modular filtering
 Problem 5: package glassfish-jaxb-txw-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(com.sun.xml.bind.mvn:jaxb-parent:pom:) = 2.2.11, but none of the providers can be installed
  - package glassfish-jaxb-parent-2.2.11-11.module+el8+2468+c564cec5.noarch requires mvn(org.apache.maven.plugins:maven-enforcer-plugin), but none of the providers can be installed
  - conflicting requests
  - package maven-enforcer-plugin-1.4.1-8.module+el8+2598+06babf2e.noarch is filtered out by modular filtering


============================================================
                       END OF ERRORS
============================================================

Version-Release number of selected component (if applicable):
leapp-upgrade-el7toel8-deps-0.17.0-1.el7_9.noarch
leapp-deps-0.15.0-2.el7_9.noarch
leapp-upgrade-el7toel8-0.17.0-1.el7_9.noarch
leapp-0.15.0-2.el7_9.noarch
python2-leapp-0.15.0-2.el7_9.noarch

How reproducible:
Everytime

Steps to Reproduce:
1. yum install glassfish-jaxb 
2. leapp preupgrade
3.

Actual results:


Expected results:
Leapp needs to either
 - enable the non-default stream when no default stream exists for the dependencies to resolve
OR
 - report some message that the package must be uninstalled before upgrading. 

Additional info:

Comment 5 Petr Stodulka 2023-01-24 14:45:23 UTC
Hi guys, can you verify that customer has up-to-date leapp metadata? From the output it seems that old data is used. I cannot reproduce the issue on my system with the latest data. The original bug has been caused by invalid events/entries specified inside pes-events.json (see the log about ADVANCED-VIRT:latest module stream that does not exist).

To the other request of being able to affect enabled / disabled modules streams, it's something what makes sense to have implemented. So despite the original bug, we agree this RFE should be introduced in one of future releases.

Comment 6 jcastran 2023-01-24 17:52:46 UTC
From the sosreport it looks like this was the previous version.

 leapp|0.12.1|1.el7_9|(none)|Red Hat, Inc.
 leapp-deps|0.12.1|1.el7_9|(none)|Red Hat, Inc. 
 leapp-repository-deps|0.14.0|4.el7_9|(none)|Red Hat, Inc. 
 leapp-repository|0.14.0|4.el7_9|(none)|Red Hat, Inc.
 python2-leapp|0.12.1|1.el7_9|(none)|Red Hat, Inc. 

I see what you mean by the ADVANCED-VIRT

# tar xf leapp-data-19.tar.gz -C /etc/leapp/files/
# cat pes-events.json | jq | grep VIRT -c
0

I don't have any copies of the old data so I'm not sure which data we are using in the case. The bug was opened 2022-12-20  so it might just be leapp-data-18 but I can't confirm that.