+++ This bug is a RHEV-M zstream clone. The original bug is: +++
+++   https://bugzilla.redhat.com/show_bug.cgi?id=1063941. +++
+++ Requested by "emesika" +++
======================================================================



----------------------------------------------------------------------
Following comment by jbelka on February 11 at 16:38:46, 2014

Created attachment 861879 [details]
setup logs

Description of problem:

Scenario:
- there's newer redhat-support-plugin-rhev and engine-setup should upgrade it. It should called update on RHEVM YUM group, but /usr/share/ovirt-engine/setup/ovirt_engine_setup/constants.py has 'UPGRADE_YUM_GROUP = 'rhevm33' and this YUM group is not found. engine-setup falls back to yum update rhevm style but this does not update redhat-support-plugin-rhev.

sbonazzo@ found that it is problem between 'rhevm33' and 'RHEV Manager' names. Changing UPGRADE_YUM_GROUP to 'RHEV Manager' made engine-setup update the plugin.

17:17 < sbonazzo> jbelka: since we call yum groups update rhevm33
...
17:18 < sbonazzo> jbelka: as I said, it's not called because not found, so fallback on yum update rhevm
...
17:23 < sbonazzo> jbelka: found the bug: it compares group name "RHEV Manager" against its id "rhevm33" :-/

[root@pb-rh33 ~]# egrep 'RHEV Manager|redhat-support-plugin' /var/log/ovirt-engine/setup/ovirt-engine-setup-20140211172614.log                   
2014-02-11 17:26:27 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages.verbose:177 Yum: queue group RHEV Manager for update
2014-02-11 17:26:29 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages.verbose:177 Yum: group RHEV Manager queued
2014-02-11 17:26:29 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages.verbose:177 Yum:     updated    - redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:29 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages.verbose:177 Yum:     update     - redhat-support-plugin-rhev-3.3.0-14.el6ev.noarch
2014-02-11 17:26:29 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:240 PACKAGE: [updated] redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:29 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:240 PACKAGE: [update] redhat-support-plugin-rhev-3.3.0-14.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [available] package redhat-support-plugin-rhev-3.3.0-14.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [installed] package redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [reinstall_available] package redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [available] package redhat-support-plugin-rhev-3.3.0-14.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [installed] package redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:30 DEBUG otopi.plugins.ovirt_engine_setup.distro-rpm.packages packages._checkForProductUpdate:254 dupes: operation [reinstall_available] package redhat-support-plugin-rhev-3.3.0-13.el6ev.noarch
2014-02-11 17:26:37 DEBUG otopi.context context.dumpEnvironment:456 ENV OSETUP_RPMDISTRO/versionLockFilter=list:'['rhevm', 'redhat-support-plugin-rhev']'

Version-Release number of selected component (if applicable):
rhevm-setup-3.3.0-0.46.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. have a repo with newer redhat-support-plugin-rhev
2. engine-setup
3.

Actual results:
redhat-support-plugin-rhev is not updated as engine-setup does not find valid YUM group and falls back to metapackage update

Expected results:
work

Additional info:

----------------------------------------------------------------------
Following comment by alonbl on February 11 at 17:23:02, 2014

This code hasn't been changed since 3.2, so either it was never tested, or the groups within the channel changed.

Nevertheless I suggest to apply this since 3.3.z.

----------------------------------------------------------------------
Following comment by aberezin on February 20 at 20:28:57, 2014

(In reply to Alon Bar-Lev from comment #1)
> This code hasn't been changed since 3.2, so either it was never tested, or
> the groups within the channel changed.
> 
> Nevertheless I suggest to apply this since 3.3.z.

Does that latest change represent the current correct group names ?

----------------------------------------------------------------------
Following comment by alonbl on February 20 at 20:33:04, 2014

(In reply to Arthur Berezin from comment #2)
> (In reply to Alon Bar-Lev from comment #1)
> > This code hasn't been changed since 3.2, so either it was never tested, or
> > the groups within the channel changed.
> > 
> > Nevertheless I suggest to apply this since 3.3.z.
> 
> Does that latest change represent the current correct group names ?

the code change is getting grp.groupid instead grp.name, in the past (3.2) there was no problem with grp.name, now (3.3) grp.name returns description and grp.groupid seems to behave nicely and probably more correct. Maybe it was yum change, not sure.