Bug 1403846 - keep 3.6 in the supportedEngines reported by VDSM
Summary: keep 3.6 in the supportedEngines reported by VDSM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 4.0.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.1.1
: ---
Assignee: Irit Goihman
QA Contact: Jiri Belka
URL:
Whiteboard:
: 1425198 (view as bug list)
Depends On:
Blocks: 1235200 1370041 1403903 1420283
TreeView+ depends on / blocked
 
Reported: 2016-12-12 13:42 UTC by Oved Ourfali
Modified: 2017-04-25 01:01 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, VDSM 4.1 didn't support a 3.6 Manager, but reported it as supported; you could add a 4.1 host to a 3.6 Manager, but would experience failures. This release removes 3.6 from the supported Manager versions, so you can not add a 4.1 host to a 3.6 Manager.
Clone Of:
Environment:
Last Closed: 2017-04-25 01:01:27 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1420283 0 urgent CLOSED Ensure that upgrading the engine vm from 3.6/el6 to 4.0/el7 is properly working once we release 4.1 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1421098 0 high CLOSED Support for el7 rhv-h-ng with rhv-3.6's vdsm-v4.17.z 2021-08-30 13:36:42 UTC
Red Hat Product Errata RHEA-2017:0998 0 normal SHIPPED_LIVE VDSM bug fix and enhancement update 4.1 GA 2017-04-18 20:11:39 UTC
oVirt gerrit 72105 0 None None None 2017-02-12 10:52:57 UTC

Internal Links: 1420283 1421098

Description Oved Ourfali 2016-12-12 13:42:05 UTC 
Description of problem:
Remove 3.6 from the supportedEngines reported by VDSM
Comment 2 Lucie Leistnerova 2017-01-26 17:19:57 UTC 
supportedENGINEs = ['4.0', '4.1']

verified in vdsm-4.19.2-2.el7ev.x86_64
Comment 3 Roman Hodain 2017-01-29 13:22:23 UTC 
This is a bit confusing. the fix is in vdsm 4.19 for 4.1, but the doc text says 4.0.

Should we backport this to 4.0?
Comment 4 Irit Goihman 2017-01-29 13:32:48 UTC 
There's an error in the doc text.
It was required to remove 3.6 from 4.1 and 3.5 from 4.0.7 and 4.1.
Comment 5 Julio Entrena Perez 2017-01-30 10:13:18 UTC 
Irit, is engine 4.0 then supported on vdsm 4.18?
Comment 6 Irit Goihman 2017-01-30 12:44:38 UTC 
Julio, yes, there is no reason it shouldn't be supported.
Comment 9 Yaniv Kaul 2017-02-06 18:41:29 UTC 
Yaniv I believe you wanted to revert this?
Comment 10 Marina Kalinin 2017-02-07 04:27:48 UTC 
(In reply to Yaniv Kaul from comment #9)
> Yaniv I believe you wanted to revert this?

Reverting this will probably help many customers upgrading from 3.6 to 4.0 hosts directly (or even 4.1 hosts), by skipping a step of upgrading hosts to latest 3.6 vdsm and related packages.
Comment 12 Marina Kalinin 2017-02-07 20:38:26 UTC 
I will set the needinfo on Yaniv back. Question to him is still relevant.
Comment 17 Yaniv Lavi 2017-02-08 10:16:03 UTC 
(In reply to Yaniv Kaul from comment #9)
> Yaniv I believe you wanted to revert this?

Yes, this is counter productive to ease of upgrades. We should add this to the testing matrix of the upgrade flow. Jiri, can you please create test cases to cover 4.x hosts in RHV 3.6 manager and 3.6 compatibility clusters?
Comment 19 Marina Kalinin 2017-02-13 22:10:23 UTC 
Before the bug moves to QA and further, we should decide on its status.

If the new 3.6 migration policy should be:
- Upgrade your hosts to 4.0 or 4.1. (note: the meaning here is, of course, clean installation on the hosts reused from current 3.6 deployment, not actual upgrade)
- Add the host to current 3.6 environment.
- Migrate the manager to 4.0. 
- Upgrade the manager to 4.1.
- Change CL level to 4.1 and done.

Then this bug should not be pushed in.
Yaniv/Jiri?
Comment 21 Jiri Belka 2017-02-14 11:59:19 UTC 
(In reply to Marina from comment #19)
> Before the bug moves to QA and further, we should decide on its status.
> 
> If the new 3.6 migration policy should be:
> - Upgrade your hosts to 4.0 or 4.1. (note: the meaning here is, of course,
> clean installation on the hosts reused from current 3.6 deployment, not
> actual upgrade)
> - Add the host to current 3.6 environment.
> - Migrate the manager to 4.0. 
> - Upgrade the manager to 4.1.
> - Change CL level to 4.1 and done.
> 
> Then this bug should not be pushed in.
> Yaniv/Jiri?

I miss the point about "migrat(ion) the manager to 4.0/4.1" and "change cl level to 4.1...".
Comment 22 Marina Kalinin 2017-02-14 21:10:17 UTC 
So, should we revert this bug?
Comment 23 Oved Ourfali 2017-02-14 21:12:58 UTC 
We pushed a patch, and then reverted it.  I guess the bug can stay as is.
Comment 24 Marina Kalinin 2017-02-14 21:15:55 UTC 
Ok, I also see the title has changed to reflect the correct requirement. 
And now Jiri will update his test plan and all seem to be ok. Thanks!
Comment 25 Oved Ourfali 2017-02-21 16:36:39 UTC 
*** Bug 1425198 has been marked as a duplicate of this bug. ***
Comment 26 Jiri Belka 2017-02-21 16:59:50 UTC 
ok, based on https://bugzilla.redhat.com/show_bug.cgi?id=1425198#c9
Comment 27 Dan Kenigsberg 2017-03-09 06:10:14 UTC 
Tahlia, I am so very sorry for having wasted your time. A version with this bug was never delivered to customers, so there is no need to document it.
Comment 28 Tahlia Richardson 2017-03-09 22:58:21 UTC 
Hi Dan, no problem, thanks for letting me know.
Note You need to log in before you can comment on or make changes to this bug.