Bug 1731033

Summary: Mixed version of packages after module install the old version module when there are 2 version of modules
Product: Red Hat Enterprise Linux 8 Reporter: yalzhang <yalzhang>
Component: virt-rhel-moduleAssignee: Jeff Nelson <jen>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: medium    
Version: ---CC: chayang, ddepaula, james.antill, jinzhao, juzhang, mblaha, psabata
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-05 18:25:13 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 yalzhang@redhat.com 2019-07-18 07:26:46 UTC
Description of problem:
Mixed version of packages after module install the old version module when there are 2 version of modules

Version-Release number of selected component (if applicable):
dnf-4.0.9.2-5.el8.noarch
yum-4.0.9.2-5.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1. Enable or reset 2 versions for the same stream of a module;
# yum module list virt
......
** 800_app ** ====> the lower version with version "820190226174025"
Name                                   Stream                                     Profiles                                     Summary                                               
virt                                   rhel [d][e]                                   common [d]                                   Virtualization module                                 

** rhel_new ** ====> the higher version 
Name                                   Stream                                     Profiles                                     Summary                                               
virt                                   rhel [d][e]                                   common [d]                                   Virtualization module     

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

2. Install the lower version of module; check the packages in the profile are from the lower version module, but some dependencies are from the higher version module, the packages will installed are mixed.
# yum module install virt:rhel:820190226174025
====================================================================================================================
 Package                                                 Arch                     Version                                                           Repository                  Size
====================================================================================================================
Installing group/module packages:
 libguestfs                                              x86_64                   1:1.38.4-10.module+el8+2709+40ed2f2c                              ** 800_app **                    2.8 M   ====> the old version
 libvirt-client                                          x86_64                   4.5.0-23.module+el8+2800+2d311f65                                 800_app                    326 k
 libvirt-daemon-config-network                           x86_64                   4.5.0-23.module+el8+2800+2d311f65                                 800_app                     26 k
 libvirt-daemon-kvm                                      x86_64                   4.5.0-23.module+el8+2800+2d311f65                                 800_app                     24 k
Installing dependencies:
 libvirt-bash-completion                                 x86_64                   4.5.0-23.module+el8+2800+2d311f65                                 800_app                     25 k
......
 libvirt-libs                                            x86_64                   4.5.0-23.module+el8+2800+2d311f65                                 800_app                    4.1 M

**************************** Below dependencies are from the new rhel module **************************************
 qemu-img                                                x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                  **   rhel_new    **                916 k  ====> the new version
 qemu-kvm                                                x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    68 k
 qemu-kvm-block-curl                                     x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    78 k
 qemu-kvm-block-gluster                                  x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    81 k
 qemu-kvm-block-iscsi                                    x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    86 k
 qemu-kvm-block-rbd                                      x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    80 k
 qemu-kvm-block-ssh                                      x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                    80 k
 qemu-kvm-common                                         x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                   899 k
 qemu-kvm-core                                           x86_64                   15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2                     rhel_new                   2.9 M
**************************** Above dependencies are from the new rhel module **************************************

Installing module profiles:
 virt/common                                                                                                                                                                        
......

Actual results:
The packages will be mixed after module install

Expected results:
The packages should not be mixed after module install

Additional info:
1) only enable the old version repo, install the old version virt module, then it will not be mixed;
2) enable the new version repo, run "yum module update", only the packages in the profile can be updated, the other packages in the module can not be updated, so the packages are mixed after update. There is an explanation in the man page:
"dnf [options] module update <module-spec>...
              Update RPMs in installed module profiles.  In case no profile was provided, all installed profiles get updated."

But I think it is not enough, all the packages should be updated as "The virt module is designed to formally couple those components that have a strong dependency between them. This is to ensure the components stay in sync with each other"

Comment 1 Jaroslav Mracek 2019-07-23 08:54:41 UTC
The command "yum module install virt:rhel:820190226174025" only installs packages mentioned in the profile in version described in virt:rhel:820190226174025. The dependencies are not covered like with other rpm operations (solver could pick anything that fulfil dependencies).

To allow behaviour that you request, the number of packages in the profile should be extended to all packages in module, or dependencies of module packagies should requires exact version.

Additionally the whole concept of modularity could be changed to provide a strict relation between module object and rpms.

Unfortunately non of above solution can be delivered by DNF team, therefore I have to change the component.

Please could you also provide information why the expected behaviour is important to you (user case behind is the most important part of the story)?

Comment 2 Jaroslav Mracek 2019-07-23 09:02:39 UTC
Or is there other opinion from modularity team how to resolve the request?

Comment 4 Jeff Nelson 2019-07-26 04:09:43 UTC
I'm strongly considering closing this as NOTABUG. I don't think a customer would find themselves in this situation: two separate repos, both with virt:rhel, but one that is newer than the other. As requested in comment 1, please provide a user story that explains why this configuration should be supported.

Comment 5 yalzhang@redhat.com 2019-07-26 08:02:27 UTC
It is the same with av virt module, like virt:8.0.0, and no need for 2 separate repos. 
Imagine that the customer only has single repo for 'latest' virt module, and they have virt:8.0.0 module installed and now comes the batch update, after they run "yum module update virt", the packages in the module will be mixed. But I'm not sure if this scenario could happen.

Comment 6 yalzhang@redhat.com 2019-07-26 08:05:34 UTC
Sorry to clear the needinfo in comment 2, add it back

Comment 7 Petr Ĺ abata 2019-07-31 10:57:30 UTC
I would also suggest closing this as a NOTABUG.  The weak link between RPMs and modules is there on purpose -- so that users can cherry-pick and lock specific NVRs if they so desire, even if that combination may not be supported by the module maintainer.

As Jaroslav says, the installation is working as expected.

If specific dependencies are required, they should indeed be either part of the profile or, even better, part of the RPM deps.  Users can also update all packages by not using the 'module' command.  Furthermore, the 'distro-sync' command can be used to install packages from the currently available content sources.

Comment 8 Jeff Nelson 2019-08-05 18:25:13 UTC
>It is the same with av virt module, like virt:8.0.0, and no need for 2 separate repos. 

But it's not the same; your example scenario used two repos each containing virt:rhel. I understand your explanation but it does not apply in this case.

>Imagine that the customer only has single repo for 'latest' virt module, and they have virt:8.0.0 module installed and now comes the batch update,
>after they run "yum module update virt", the packages in the module will be mixed. But I'm not sure if this scenario could happen.

It cannot. If it can, please open a bug report that illustrates this exact issue.

Closing this BZ as NOTABUG. This scenario is not a valid use of virt:rhel and is not supported.