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

[Dan Kenigsberg]

On Mon, May 21, 2012 at 09:55:11AM -0400, 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.

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.