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

[Yair Zaslavsky]

On 05/21/2012 04:55 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: users at ovirt.org
>> Sent: Monday, May 21, 2012 4:46:20 PM
>> Subject: Re: [Users] Host can't jo­in the cluster
>>
>> 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
>> VDSM)
>> Thoughts about this are more than welcome
>>
>> Yair
> 
> i agree with this approach,
> just one fix, we should use vdsm's 'supportedProtocols'
> which match the engine's cluster levels.
> this way the versions of the software are not important,
> only what 'protocols' (or cluster levels) are supported in both.

Exactly, my bad.
Thanks for the correction!


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