Bug 883530

fedora note: Juan already made the inquiries, they have one global yum groups file, we can ask for group definition and modification.

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.

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?

(In reply to comment #3)
> I presume the grouping that we are talking about does not remove this
> requirement?

Right.

Jan,

Can you please add the group?

Thanks!
Alon

From: "Jay Greguske" <jgregusk>
To: "Alon Bar-Lev" <alonbl>
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'.

commit ba6411e02e53c4c7e2a171ca18af10047263fa3a
Author: Alon Bar-Lev <alonbl>
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>

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

Mandatory dependencies:

commit 42a8e9d22ec9a466ebf256075dc2d090ec9aa0c3
Author: Alon Bar-Lev <alonbl>
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>

http://gerrit.ovirt.org/#/c/10308/1

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.

(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?

We have rhevm31, rhevm32

Hello Jay,

Can you please assist?

Thanks!

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.

I'm embarassed to admit I misplaced the package list you sent me a while ago. Could you re-send it here? :/

(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

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.

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

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

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!

should this group include (some as optional):
-dwh
-reports
-rhev support ui-plugin
-virtio-win
-sdk
-cli
-spice-client
-vdsm-bootstap (legacy-support)

(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.

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

3.2 has been released

3.2 has been released

3.2 has been released

3.2 has been released