[ovirt-devel] Adding support for 3.6 in engine database

Dan Kenigsberg danken at redhat.com
Wed Jan 14 13:15:02 UTC 2015


On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote:
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Lior Vernia" <lvernia at redhat.com>, "Oved Ourfali" <oourfali at redhat.com>
> > Cc: "engine-devel at ovirt.org" <devel at ovirt.org>, "Dan Kenigsberg" <danken at redhat.com>, "Yaniv Bronheim"
> > <ybronhei at redhat.com>
> > Sent: Thursday, January 8, 2015 3:41:31 PM
> > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Lior Vernia" <lvernia at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel at ovirt.org" <devel at ovirt.org>, "Dan Kenigsberg"
> > > <danken at redhat.com>, "Yaniv Bronheim"
> > > <ybronhei at redhat.com>
> > > Sent: Thursday, January 8, 2015 3:08:24 PM
> > > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database
> > > 
> > > Tried to work with it, and noticed that:
> > > 1. The engine doesn't list 4.17 as a supported vdsm version.
> > > 2. 4.17 vdsm doesn't report 3.6 as a supported engine version.
> > > 
> > > This basically means that no host could be operational in a 3.6 cluster,
> > > as to my understanding 4.17 is exactly the version supporting 3.6
> > > functionality.
> > > 
> > > May I send a fix for (1), or is there any argument against? And who
> > > could take care of (2)?
> > 
> > I had understood deom Oved that this is 4.16 see patch
> > http://gerrit.ovirt.org/#/c/36511/
> > Oved ???
> > 
> 
> I don't know when we should add 4.17. I remember there is some "policy" for that.
> Dan?

Yes, there is.

Vdsm would like to declare its support of clusterLevel 3.6 only when it
actually does. This is not yet the case, as we are not yet in 3.6
feature freeze (heck, we're not yet in feature definition).

To test cluster level 3.6 on the master branch, someone has to "lie".

It may be Vdsm (by claiming that it supports 3.6 while it does
not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it
does not).

I prefer the latter, as the Engine-side hack is eaiser to undo on a
distributed system. If today's Vdsm claims that it already support 3.6,
future Engines would add it to their cluster, only to find that random
APIs fails. If the hack is Engine-side, it would be gone when 3.6
reaches feature freeze.

Dan.



More information about the Devel mailing list