Bug 880069

Summary:	[rhevm-upgrade] pre-upgrade checks should collect all needed actions from user and not exit when one of them is no fulfilled
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Haim <hateya>
Component:	ovirt-engine-setup	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	sefi litmanovich <slitmano>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.2.0	CC:	acathrow, bazulay, iheim, jkt, oschreib, pstehlik, Rhev-m-bugs, yeylon
Target Milestone:	---	Keywords:	Triaged
Target Release:	3.3.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	integration
Fixed In Version:		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:	---	Target Upstream Version:
Embargoed:

Description Haim 2012-11-26 07:23:05 UTC

Description of problem:

this is a pure UX case where I had to run rhevm-upgrade 3 times before it actually did something.

1) execute rhevm-upgrade

result: script starts, after 5 minutes I get message that i need to upgrade my rhevm-setup package

mitigation: upgraded rhevm-setup and try again

2) execute rhevm-upgrade

result: script starts, after 5 minutes I get message that I have an IPA installation which I need to remove (no KB for that)

mitigation: yum remove ipa-server and try again

3) execute rhevm-upgrade 

result: script starts, after 5 minutes I get a message that I have other ISO\EXPORT domain over iSCSI\FC which I need to remove.

mitigation: log-in to system, remove block based EXPORT domain and try again.

obviously, you can understand its a bad user experience.

Comment 1 Itamar Heim 2012-11-26 11:21:06 UTC

the first one detects there is a new version.
the new version added a new check
the 3rd one could be combined with the 2nd one maybe, but not sure worth it for that specific corner case.

Comment 2 Simon Grinberg 2012-12-24 18:14:02 UTC

(In reply to comment #1)
> the first one detects there is a new version.

Should be the first check, and not wait to get a full list of required RPM for the upgrade.

> the new version added a new check

No problem, but again why wait? There are few checks that are not dependent on the set of RPMs to be installed. They should run prior to the accumulation of the full RPM list thus saving the user an idle wait 


> the 3rd one could be combined with the 2nd one maybe, but not sure worth it
> for that specific corner case.

Same as in the previous comment.

Comment 6 sefi litmanovich 2013-10-03 10:50:06 UTC

Current upgrade flow, RHEVM 3.3 upgrading form IS16 to IS17 on RHEL 6.5 machine.

after updating the repos:
1. run engine-setup:
 - after 30 seconds setup is srearching for updates
 - answer yes to update the packages
 - get error message: 

[ ERROR ] An update for the Setup package "rhevm-setup" was found. Please update that package, e.g. by running "yum update rhevm-setup", and then execute Setup again.
[ ERROR ] Failed to execute stage 'Environment customization': Please update the Setup package

setup stops.

2. 
 - run yum update rhevm-setup.
 - run engine-setup.
 - setup flow works fine with no problems including yum updating the 
   relevant rhevm packages.

Comment 7 Yedidyah Bar David 2013-10-06 11:45:55 UTC

As explained before, yum downloads metadata once, then reads from the cache.

I now did the following tests, all on a fedora 19 machine with ovirt 3.3 beta installed and the nightly repo enabled.

1. Ran a few times:
/usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 12 seconds, average, not including the first, around 13 seconds.

2. Ran a few times:
yum clean all; /usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 38 seconds, average around 42 seconds.

3. Then changed the sources to check for an update for setup before checking an update for the engine, here:
http://gerrit.ovirt.org/19892

4. Again, ran a few times:
/usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 11 seconds, average around 12 seconds. One second less than without the change.

5. Ran a few times:
yum clean all; /usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was again around 38 seconds, average around 40 seconds.

Conclusion: Updating the metadata cache takes around 30 seconds, the rest is relatively insignificant. IMHO, of course :-)

Do we want such a change?

Note that it works, but probably not ready for merge - in particular, the current master code relies on a single environment value (OSETUP_RPMDISTRO/enableUpgrade) to decide if the user wants to upgrade both the product and setup, while the code with the change checks updates for setup unconditionally - and we might want to add another value for that or use the existing one. Not sure which is best.

Comments are welcome.

Comment 8 Yedidyah Bar David 2013-10-09 13:00:47 UTC

Now talked with Sefi about his tests.

We both agreed there is currently no issue.

I am moving to ON_QA, letting Sefi move to VERIFIED.

Comment 9 sefi litmanovich 2013-10-09 13:10:11 UTC

Verified on RHEL 6.5 RHEVM 3.3 IS17.

Comment 11 Itamar Heim 2014-01-21 22:28:24 UTC

Closing - RHEV 3.3 Released

Comment 12 Itamar Heim 2014-01-21 22:28:30 UTC

Closing - RHEV 3.3 Released

Comment 13 Itamar Heim 2014-01-21 22:31:22 UTC

Closing - RHEV 3.3 Released

Comment 14 Red Hat Bugzilla 2023-09-14 01:39:04 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days