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. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
