Bug 1425660

Summary:	Upgrade button is unavailable in engine 3.6 when upgrade NGN-3.6 to 4.x node in engine side
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Huijuan Zhao <huzhao>
Component:	ovirt-engine	Assignee:	Nobody <nobody>
Status:	CLOSED WONTFIX	QA Contact:	Huijuan Zhao <huzhao>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.6.10	CC:	cshao, dguo, gklein, jiawu, leiwang, lsurette, mperina, rbalakri, rbarry, Rhev-m-bugs, srevivo, weiwang, yaniwang, ycui, ykaul, ylavi, yzhao
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-08 06:59:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1421098

Description Huijuan Zhao 2017-02-22 01:14:19 UTC

Description of problem:
Upgrade button is unavailable(grey) in engine 3.6 when upgrade NGN-3.6 to 4.x node in engine side

Version-Release number of selected component (if applicable):
From:
RHVH-3.6-20170217.5-RHVH-x86_64-dvd1.iso
To:
redhat-virtualization-host-4.1-20170208.0

How reproducible:
100%

Steps to Reproduce:
1. Install RHVH 3.6 RHVH-3.6-20170217.5-RHVH-x86_64-dvd1.iso
2. Setup local repos in RHVH 3.6, then add it to engine 3.6(cluster 3.6)
   Run "yum update" in RHVH-3.6 can detect newer build redhat-virtualization-host-4.1-20170208.0, quit update process.
3. Login rhevm, set upgrade detect interval time as 1 hour
   # engine-config -s HostPackagesUpdateTimeInHours=1
   # service ovirt-engine restart
4. Wait for more than 1 hour, check Upgrade button in engine 3.6

Actual results:
After step4, Upgrade button in engine 3.6 is unavailable(grey) all the time

Expected results:
After step4, Upgrade button in engine 3.6 should be available and can upgrade NGN-3.6 to newer 4.x node from engine side

Additional info:

Comment 1 Yaniv Kaul 2017-02-22 11:45:51 UTC

I think it's OK - I don't expect a 3.6 engine to be able to upgrade an NGN RHVH. It can be upgraded via the RHVH itself - Ryan - can you confirm?

Comment 2 Ryan Barry 2017-02-22 13:20:59 UTC

Correct -- it can be upgraded via RHVH itself, especially if 'yum update' can see it.

In order for this to work otherwise, engine would need a backport of this topic branch: https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:NGN

Recommending that users upgrade from the host is ok here.

Comment 3 Yaniv Kaul 2017-02-22 13:22:46 UTC

I don't think we are going to backport this - Yaniv D. - please CLOSE-WONTFIX.

Comment 4 Yaniv Lavi 2017-02-27 13:55:01 UTC

This would mean we will need to run the yum command as part of the field engineering effort without the update manager orchestration. I that acceptable to you?

Comment 5 Yaniv Kaul 2017-02-27 14:17:35 UTC

(In reply to Yaniv Dary from comment #4)
> This would mean we will need to run the yum command as part of the field
> engineering effort without the update manager orchestration. I that
> acceptable to you?

Yes. I'm hoping it can be scripted via Ansible.

Comment 6 Ying Cui 2017-03-01 04:17:19 UTC

Yaniv D. 
step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3: (upgrade) el7-4.y-ngn.
According to comment 3, comment 4, and comment 5, so we won't support step 2 to step 3 upgrade via engine 3.6, could you ack this, and then close this bug as WON'T fix?

Comment 7 Yaniv Lavi 2017-03-01 09:52:38 UTC

(In reply to Yaniv Kaul from comment #5)
> (In reply to Yaniv Dary from comment #4)
> > This would mean we will need to run the yum command as part of the field
> > engineering effort without the update manager orchestration. I that
> > acceptable to you?
> 
> Yes. I'm hoping it can be scripted via Ansible.

Ansible is a much weaker solution than the upgrade manager.
This would mean rewriting this code in Ansible. Is that what we want?


(In reply to Ying Cui from comment #6)
> Yaniv D. 
> step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3:
> (upgrade) el7-4.y-ngn.
> According to comment 3, comment 4, and comment 5, so we won't support step 2
> to step 3 upgrade via engine 3.6, could you ack this, and then close this
> bug as WON'T fix?

Ying, I'm still not sure. Let close this discussion first.

Comment 8 Yaniv Kaul 2017-03-01 11:11:14 UTC

(In reply to Yaniv Dary from comment #7)
> (In reply to Yaniv Kaul from comment #5)
> > (In reply to Yaniv Dary from comment #4)
> > > This would mean we will need to run the yum command as part of the field
> > > engineering effort without the update manager orchestration. I that
> > > acceptable to you?
> > 
> > Yes. I'm hoping it can be scripted via Ansible.
> 
> Ansible is a much weaker solution than the upgrade manager.

Not for RHVH.

> This would mean rewriting this code in Ansible. Is that what we want?

For RHVH, yes. It's quite simple actually.

> 
> 
> (In reply to Ying Cui from comment #6)
> > Yaniv D. 
> > step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3:
> > (upgrade) el7-4.y-ngn.
> > According to comment 3, comment 4, and comment 5, so we won't support step 2
> > to step 3 upgrade via engine 3.6, could you ack this, and then close this
> > bug as WON'T fix?
> 
> Ying, I'm still not sure. Let close this discussion first.

Comment 9 Yaniv Kaul 2017-03-07 13:12:37 UTC

Yaniv?

Comment 10 Martin Perina 2017-03-08 06:59:55 UTC

Handling NGN upgrades within host upgraded manager is engine 4.0 feature, in 3.6 you need to invoke yum directly to perform an upgrade. Based on above comments I'm closing this as WONTFIX, but feel free to reopen and please present other arguments why we should backport the feature.

Comment 11 Yaniv Lavi 2017-03-09 10:51:26 UTC

(In reply to Yaniv Kaul from comment #9)
> Yaniv?

If you believe scripting this would be easier than this can remain closed.