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.
Dan.