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