Bug 883530 - 3.2 - upgrade: use yum group to force upgrade components during engine-upgrade
3.2 - upgrade: use yum group to force upgrade components during engine-upgrade
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.0
Assigned To: Alon Bar-Lev
Jiri Belka
integration
:
Depends On: 927322
Blocks: 915537
  Show dependency treegraph
 
Reported: 2012-12-04 15:03 EST by Alon Bar-Lev
Modified: 2013-06-11 04:44 EDT (History)
15 users (show)

See Also:
Fixed In Version: sf-8
Doc Type: Bug Fix
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: ---


Attachments (Terms of Use)

  None (edit)
Description Alon Bar-Lev 2012-12-04 15:03:07 EST
Currently engine-upgrade contain a list of satellite packages that PM defined that needs to be updated with engine-upgrade is executed.

This is somewhat non-standard approach, as usually "yum update" should be used to update the system, and utility to update component is not actually required. However, yum package manager lacks the ability to update a package with all its dependencies.

However, keeping the original requirement, is is not wise to list packages outside of ovirt-engine scope within the ovirt-engine scripts, as the decision whether or not to upgrade a specific component should not require a code change.

This is where yum groups entering the picture. If we define a yum group of ovirt-engine-components, we can upgrade an entire group within the engine-upgrade without any knowledge of the group content. The group content may be changed at will without effecting the implementation.

Jay will define such a group for us to test at the 3.2 channel.

Miniyum support for yum groups is already established.
Comment 1 Alon Bar-Lev 2012-12-04 15:06:28 EST
fedora note: Juan already made the inquiries, they have one global yum groups file, we can ask for group definition and modification.
Comment 2 Juan Hernández 2012-12-08 07:22:17 EST
Note that we should also use yum groups to break some artificial dependencies that we currently use just to simplify the installation instructions. For example, the backend package should not require the log collector, the iso uploader or the image uploader. Instead of that they should be mandatory packages in in the rhevm package group.

Same for webadmin and user portal, in my opinion the backend should not require them, or the other way around. Rather backend and webadmin should be independent packages (generated from the same source package) and then they can be mandatory packages of the group.

Doing this the user should only need to do "yum groupinstall rhevm" to get everything.
Comment 3 Andrew Cathrow 2012-12-09 11:33:23 EST
The original goal of the packages that were listed was to ensure that a core set of package were NOT upgraded when a user ran yum upgrade. Since upgrading some of the core packages would restart services, potentially change critical files and potentially fail leaving the system in a state where it needed manual recovery, we wanted a way to ensure that a user could simply run yum upgrade and know that this was a "safe" operation to perform. The packages listed where ones that were to be locked by yum to prevent accidental and unmanaged RHEV upgrades.

I presume the grouping that we are talking about does not remove this requirement?
Comment 4 Alon Bar-Lev 2012-12-09 13:16:36 EST
(In reply to comment #3)
> I presume the grouping that we are talking about does not remove this
> requirement?

Right.
Comment 5 Alon Bar-Lev 2012-12-19 13:50:33 EST
Jan,

Can you please add the group?

Thanks!
Alon
Comment 6 Alon Bar-Lev 2012-12-21 14:43:59 EST
From: "Jay Greguske" <jgregusk@redhat.com>
To: "Alon Bar-Lev" <alonbl@redhat.com>
Sent: Friday, December 21, 2012 9:18:42 PM
Subject: Re: Yum package groups in RHN

I've made the groups available in the QA and errata.stage RHN
environments.
<snip>
The name of the group is 'rhevm'.
Comment 7 Alon Bar-Lev 2012-12-21 17:39:00 EST
commit ba6411e02e53c4c7e2a171ca18af10047263fa3a
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Fri Dec 21 22:46:25 2012 +0200

    packaging: upgrade: support engine yum group
    
    Change-Id: Iafbd1aac08925f4476fa83427a35070a4e29fe34
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

http://gerrit.ovirt.org/#/c/10311/

Mandatory dependencies:

commit 42a8e9d22ec9a466ebf256075dc2d090ec9aa0c3
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Fri Dec 21 21:36:33 2012 +0200

    packaging: sync miniyum implementation with recent otopi
    
    Change-Id: I232c2c6d477aec5aa1fc5a764b49f153dc61e648
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

http://gerrit.ovirt.org/#/c/10308/1
Comment 11 Jay Greguske 2013-01-07 12:48:36 EST
If you have 2 groups with the same name the package lists will be merged together. If that is not a desired behavior, then we probably do want to have versions in the package group IDs.
Comment 12 Alon Bar-Lev 2013-01-07 13:37:43 EST
(In reply to comment #11)
> If you have 2 groups with the same name the package lists will be merged
> together. If that is not a desired behavior, then we probably do want to
> have versions in the package group IDs.

I think we do want... can you please rename the group to rhevm-3.2?
Comment 13 Alon Bar-Lev 2013-01-24 16:36:07 EST
We have rhevm31, rhevm32
Comment 15 Alon Bar-Lev 2013-03-21 11:18:42 EDT
Hello Jay,

Can you please assist?

Thanks!
Comment 16 Jay Greguske 2013-03-21 12:59:39 EDT
I only made the changes on rhn.qa, and by now they were probably wiped out. rhn.qa gets "cloned" from production each month, so any changes made there and not production get destroyed eventually. I'll let you know when they're back.
Comment 17 Jay Greguske 2013-03-21 14:11:22 EDT
I'm embarassed to admit I misplaced the package list you sent me a while ago. Could you re-send it here? :/
Comment 18 Alon Bar-Lev 2013-03-21 14:48:37 EDT
(In reply to comment #17)
> I'm embarassed to admit I misplaced the package list you sent me a while
> ago. Could you re-send it here? :/

rhevm
rhevm-backend
rhevm-config
rhevm-dbscripts
rhevm-genericapi
rhevm-notification-service
rhevm-restapi
rhevm-setup
rhevm-tools-common
rhevm-userportal
rhevm-webadmin-portal
ovirt-image-uploader
ovirt-iso-uploader
ovirt-log-collector
otopi
ovirt-host-deploy
Comment 19 Jay Greguske 2013-03-22 09:14:29 EDT
Done in the rhn.qa environment again. The 3.2 channel does not have any packages in it. I won't be able to add them until we're in beta.
Comment 20 Jiri Belka 2013-03-25 10:35:50 EDT
OK, with QA RHN. (This cannot be practically tested until 3.2 is in RHN, see comment #19, we are using internal build repos.)

# grep serverURL /etc/sysconfig/rhn/up2date 
serverURL[comment]=Remote server URL (use FQDN)
serverURL=https://xmlrpc.rhn.qa.redhat.com/XMLRPC
[root@jb-rh31 ~]# rhn-channel -l
rhel-x86_64-server-6
rhel-x86_64-server-6-rhevm-3.2

# yum grouplist -v | grep -i rhevm | tail -n1
   RHEV Manager (rhevm32)

# yum groupinfo rhevm32
Loaded plugins: rhnplugin, security, versionlock
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Group Process

Group: RHEV Manager
 Description: Red Hat Enterprise Virtualization Manager packages
 Mandatory Packages:
   otopi
   ovirt-host-deploy
   rhevm
   rhevm-backend
   rhevm-config
   rhevm-dbscripts
   rhevm-genericapi
   rhevm-image-uploader
   rhevm-iso-uploader
   rhevm-log-collector
   rhevm-notification-service
   rhevm-restapi
   rhevm-setup
   rhevm-tools-common
   rhevm-userportal
   rhevm-webadmin-portal
Comment 21 Jiri Belka 2013-03-25 11:38:10 EDT
Please ensure next build repodata dir would contain xml file for groups, so we can test that upgrade is upgrading rhevm based on yum group and not based on rpm packages list. Changes for rhevm rpm metadata are needed. Otherwise there is not way QE can test this.

In SF11 I can see the changes are present in upgrade scripts but SF11 yum metadata do not have any group in repository.

# grep ^ENGINE_YUM /usr/share/ovirt-engine/scripts/basedefs.py
ENGINE_YUM_GROUP="rhevm32"

I mirrored repodata dir for SF11.

$ pwd
/tmp/bob.eng.lab.tlv.redhat.com/builds/sf11/repodata
$ zcat *.gz | awk '/<group>$/ { getline; print ; getline; print; }' | grep -i rhev
$ ls
filelists.xml.gz  index.html?C=D;O=A  index.html?C=M;O=A  index.html?C=N;O=A  index.html?C=S;O=A  other.xml.gz    repomd.xml
index.html        index.html?C=D;O=D  index.html?C=M;O=D  index.html?C=N;O=D  index.html?C=S;O=D  primary.xml.gz
Comment 22 Alon Bar-Lev 2013-03-25 11:53:39 EDT
Hi,

What you are testing in this bug is the code change, not the channel. You can leave it in ON_QA for now until channel is setup properly as Jay wrote in comment#19.

Thanks!
Comment 23 Moran Goldboim 2013-04-28 09:22:31 EDT
should this group include (some as optional):
-dwh
-reports
-rhev support ui-plugin
-virtio-win
-sdk
-cli
-spice-client
-vdsm-bootstap (legacy-support)
Comment 24 Alon Bar-Lev 2013-04-28 09:38:36 EDT
(In reply to comment #23)
> should this group include (some as optional):
> -dwh
> -reports
> -rhev support ui-plugin
> -virtio-win
> -sdk
> -cli
> -spice-client
> -vdsm-bootstap (legacy-support)

No, group should only contain the minimum rhevm packages, needed to be upgraded using engine-upgrade.

If the name rhevm32 is misleading in this sense we should rename the group to rhevm32-engine or any other suitable name.

Regardless, the vdsm-bootstrap is obsolete in rhevm-3.2, and should not be considered to any usage.
Comment 29 Jiri Belka 2013-05-14 05:52:37 EDT
ok, sf16.

2013-05-13 09:56:27::DEBUG::rhevm-upgrade::316::root:: Transaction Summary:
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-backend-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-config-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-dbscripts-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-genericapi-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-notification-service-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-restapi-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-tools-common-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-userportal-3.2.0-10.25.beta3.el6ev.noarch
2013-05-13 09:56:27::DEBUG::rhevm-upgrade::320::root::     update - rhevm-webadmin-portal-3.2.0-10.25.beta3.el6ev.noarch
Comment 30 Itamar Heim 2013-06-11 04:36:08 EDT
3.2 has been released
Comment 31 Itamar Heim 2013-06-11 04:36:08 EDT
3.2 has been released
Comment 32 Itamar Heim 2013-06-11 04:36:14 EDT
3.2 has been released
Comment 33 Itamar Heim 2013-06-11 04:44:45 EDT
3.2 has been released

Note You need to log in before you can comment on or make changes to this bug.