On Mon, May 21, 2012 at 09:55:11AM -0400, Omer Frenkel wrote: > > > ----- Original Message ----- > > From: "Yair Zaslavsky" <[email protected]> > > To: "Itamar Heim" <[email protected]> > > Cc: [email protected] > > Sent: Monday, May 21, 2012 4:46:20 PM > > Subject: Re: [Users] Host can't join 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.
Is supportedProtocols ever used by Engine now? I think it is stale. I resent introducing it, as the logic is too complex as it is. I think it is enough to have a set of SupportedVDSMVersions, with the extra ability to ship a vdsm with another version, reporting its supportedeRHEVMs. It is unlikely that vdsm is ever shipped without a change to the protocol (we are not in the business of reimplementation of old APIs). So supportedProtocols is not going to change any slower than vdsm version. Please add vdsm-4.9.6 to the set of SupportedVDSMVersions. _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
