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

[Omer Frenkel]

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

> 
> 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>