[Users] Host can't jo­in the cluster

Yair Zaslavsky yzaslavs at redhat.com
Mon May 21 13:46:20 UTC 2012

On 05/19/2012 05:54 PM, Itamar Heim wrote:
> On 05/18/2012 04:20 PM, Dan Kenigsberg wrote:
>> On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote:
>>> On 05/17/2012 02:11 PM, Omer Frenkel wrote:
>>> ...
>>>>> second, iirc, the definition was vdsm can override engine vdsm
>>>>> version
>>>>> check, so a newer vdsm could still report it will work with an older
>>>>> engine, without needing to change the older engine to match it?
>>>> i agree as well, i think the intention was for newer builds in the
>>>> same version,
>>>> so revision can be changed, but major version should be coordinated
>>>> with the engine.
>>>> maybe the logic can changed just to make sure
>>>> there is a match between supported cluster levels in vdsm and engine
>>>> and ignore engine / vdsm software versions
>>> indeed.
>>> and code seems to be correct for that flow.
>>> either engine has support for vdsm version.
>>> or
>>> vdsm reports it supports this engine version.
>>> so danken - i think the missing part is actually vdsm telling engine
>>> 3.1 version is supported:
>>> in
>>> ./vdsm/dsaversion.py.in:    'supportedRHEVMs': ['3.0'],
>>> (and yes, need to change this to supportedEngine naming, but i
>>> suggest doing this in a separate patch for engine to do this with
>>> backward compatibility)
>> I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think
>> that if vdsm reports that it supports clusterLevel 3.1, Engine should
>> believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms
>> tell old Engines that they are fine. That should not be the main path of
>> fixing the issue.
> I think there was some concept of distinguishing between supported
> compatibility levels vs. supported versions of engine with that
> compatibility level if engine did not specify it supports that vdsm
> version (i.e., tested and supported vs. we just think this should work)
Itamar - this is true.
The misleading error occurs as at engine code we use the same message
for both cases.
We can separate to having two error messages:
a. Incompatible cluster level
b. VDSM version not supported.

However, if we use this, it means that after every release of VDSM, we
should update the SupportedVDSMVersions (i.e - add 4.9.6 to it)
Is this what we want to do?
The other option -as previously mentioned is to rely only on cluster
compatibility level comparison  (using the 'supprtedRHEVMs' reported by
Thoughts about this are more than welcome


> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

More information about the Users mailing list