Bug 1120267

Summary:	Host can't join cluster with level 3.3. when installing vdsm 4.14
Product:	[Retired] oVirt	Reporter:	Sven Kieske <s.kieske>
Component:	ovirt-engine-core	Assignee:	Yaniv Bronhaim <ybronhei>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	3.3	CC:	amureini, bazulay, bugs, dougsland, ecohen, gklein, iheim, MichaelG15, michal.skrivanek, rbalakri, s.kieske, tnisan, ybronhei, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-09-14 14:40:43 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:

Description Sven Kieske 2014-07-16 15:14:10 UTC

Description of problem:
I get: Host xxx is installed with VDSM version (4.14) and cannot join  cluster YYYY which is compatible with VDSM versions [4.13, 4.9,  4.11, 4.12, 4.10]. cluster level is 3.3 this should work, shouldn't it?

Version-Release number of selected component (if applicable):
rpm -qa | grep vdsm
vdsm-xmlrpc-4.14.6-0.el6.noarch
vdsm-4.14.6-0.el6.x86_64
vdsm-python-zombiereaper-4.14.6-0.el6.noarch
vdsm-python-4.14.6-0.el6.x86_64
vdsm-cli-4.14.6-0.el6.noarch

engine version: 3.3.3-2

How reproducible:
always

Steps to Reproduce:
1. yum -y install http://resources.ovirt.org/pub/ovirt-3.3/rpm/el6/noarch/ovirt-release-el6-10.0.1-2.noarch.rpm
2. add host through webadmin
3. watch above failure

Actual results:
wrong vdsm version gets installed

Expected results:
compatible vdsm version gets installed

Additional info:

workaround:
yum downgrade vdsm*
#watch some errors during downgrade...
cp /etc/vdsm/vdsm.conf.rpmsave /etc/vdsm/vdsm.conf

Comment 1 Tal Nisan 2014-07-17 06:03:07 UTC

Alon, why did you mark it as storage? I don't see how this is related to storage in any way

Comment 2 Yaniv Bronhaim 2014-09-04 02:54:01 UTC

what is the cluster version of YYYY ? vdsm 4.14.6 should fit to clusters older or equal to 3.4. We have in 3.3.3-rc1, which is the last tag i see for 3.3.3, all recent changes we did around HandleVdsVersionCommand

Comment 3 Sven Kieske 2014-09-04 07:14:56 UTC

to quote myself:
(In reply to Sven Kieske from comment #0)
> cluster level is 3.3 this should work, shouldn't it?

Comment 4 Yaniv Bronhaim 2014-09-05 20:06:31 UTC

Just tried that with latest 3.4 which is vdsm-4.14.15 and latest 3.5 engine. Added the host to cluster 3.3 and host became up properly. so it probably in CURRENTRELEASE. can you confirm that?

Comment 5 Sven Kieske 2014-09-08 09:11:14 UTC

No I can not confirm this, as I have no installation with 3.5 engine installed, nor have I the time or resources to do so atm, sorry.

Maybe first you should try to reproduce on latest 3.3.z or if this is to old
on the current released latest version.

I really wonder why you guys first test vs a non GA released version, I know
it might be handy because as a dev you have it installed anyway.

But from a customer/user perspective it's not helpful at all.

All we know now is that this issue does not exist in 3.5 RC (according to you).

But do you want to advise me to install a release candidate on a production system?

I really would like to know if this issue is present in 3.4.4. RC
or 3.4.3, as those are the next versions I want to upgrade to (eventually)-

I really don't know if this provides the information you needed.

Comment 6 Yaniv Bronhaim 2014-09-08 16:27:58 UTC

it does provide, thanks
because the bug is targeted to 3.5 I check only that version... otherwise we should change the target release to 3.3\3.4 and then we'll get the acks if we'll decide to respin for that issue. but as long as it aims to 3.5, I check if its not already work in this version before starting to debug. and it seems to work properly according to your description 

correct me if im wrong, and update the bug accordingly (target release 3.4?)

Comment 7 Michael Gregg 2014-09-08 18:05:28 UTC

It looks like the target needs to be changed to 3.3 on this BZ.

I switched to using 3.4, where this issue does not exist. 

This issue exists on 3.3 engines. I originally started using 3.3 because the code looked like it was in a stable state.

It appears that the majority of contributions are on 3.4 and 3.5. Is 3.3 abandonware at this time?

Comment 8 Sven Kieske 2014-09-09 07:48:23 UTC

@ Michael: Well 3.3 doe not get future updates, the latest released version in this branch is 3.3.5. The current stable branch is 3.4. with 3.4.4 being released soon. 3.5. should be also soon be released but there are still some bugs
being worked on.

@Yaniv: I did not set the Target Release, that was Itamar, I also can not change
it, as I don't have the permissions to do so.

I'd like to know if this problem does exist in 3.4.3/4

Also I'd like some more documentation about which ovirt-engine version
runs well with which vdsm version (it's sad but understandable that they have different version numbers).

Thanks

Sven

Comment 9 Michael Gregg 2014-09-09 16:14:22 UTC

This issue does not exist in 3.4. I am currently using 3.4 without problems. 

This issue seems to only exist in the current 3.3 builds.

Comment 10 Barak 2014-09-14 14:40:43 UTC

Per the comments above,
This happens only on 3.3.x engine, and does not happen on 3.4.0 and above.
As we do not release any more updates of 3.3, moving to CLOSED CURRENTRELEASE.

Comment 11 Michael Gregg 2014-09-15 18:23:56 UTC

Would it not be more appropriate to move this to Closed -> Wontfix?

This issue still exists on the older platform.