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
Alon, why did you mark it as storage? I don't see how this is related to storage in any way
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
to quote myself: (In reply to Sven Kieske from comment #0) > cluster level is 3.3 this should work, shouldn't it?
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?
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.
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?)
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?
@ 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
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.
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.
Would it not be more appropriate to move this to Closed -> Wontfix? This issue still exists on the older platform.