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

[Itamar Heim]

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)