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