[Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine

[Yedidyah Bar David]

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "Yedidyah Bar David" <didi at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 17, 2014 10:08:31 AM
> Subject: Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Yedidyah Bar David" <didi at redhat.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, March 17, 2014 9:11:20 AM
> > Subject: Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds
> > running the VM with the hosted engine
> > 
> > Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >> To: "Yedidyah Bar David" <didi at redhat.com>
> > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> > >> <jmoskovc at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>
> > >> Sent: Sunday, March 16, 2014 12:47:43 PM
> > >> Subject: Re: Bug 1076530 – engine shouldn't kill the vds running the VM
> > >> with the hosted engine
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Yedidyah Bar David" <didi at redhat.com>
> > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> > >>> <jmoskovc at redhat.com>
> > >>> Sent: Sunday, March 16, 2014 12:28:27 PM
> > >>> Subject: Re: Bug 1076530 – engine shouldn't kill the vds running the VM
> > >>> with the hosted engine
> > >>>
> > >>> Might be better to discuss this on bugzilla.
> > >>>
> > >> Bugzilla is not a mailing list. Moving to engine-devel.
> > >>
> > >>> ----- Original Message -----
> > >>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>>> Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
> > >>>> <jmoskovc at redhat.com>
> > >>>> Sent: Sunday, March 16, 2014 12:01:51 PM
> > >>>> Subject: Bug 1076530 – engine shouldn't kill the vds running the VM
> > >>>> with
> > >>>> the hosted engine
> > >>>>
> > >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> > >>>>
> > >>>> Sandro,
> > >>>> I think this would be solved by a better validation during setup /
> > >>>> deployment.
> > >>>
> > >>> This can't be done during Validation in the otopi sense of the word.
> > >>> At that point the engine does not exist yet and so we can't know what
> > >>> versions it supports etc.
> > >>>
> > >> Why not?
> > >> You have the vdsm supported versions in a file (dsaversion IIRC)
> > >> and you should be able to get the relevant engine info before or
> > >> after deploying the DB.
> > > 
> > > The VM does not exist yet at that point. How can you know what the user
> > > will install on it? You can tell them what they *should* install - e.g.
> > > "The highest compatibility version supported by this host is 3.4, you
> > > should install a 3.4 engine inside the engine VM". But we can't know what
> > > the user actually did until after we connect to the installed and working
> > > engine.
> > > 
> > >>
> > >>> It might be possible (didn't check) to check the versions right before
> > >>> trying to add the host to the cluster. This means we do not want to
> > >>> abort (as we can do during Validation if something does not pass it).
> > >>> What can we do? Perhaps offer a few options:
> > >>> 1. Do abort (will do mostly what happens today)
> > >>> 2. Let the user try to manually fix, probably by trying to change
> > >>> the compatibility version of the cluster, and then try adding the
> > >>> host again
> > >>> 3. Try to fix ourselves (same) and try adding again
> > >>> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> > >>> Not sure that's easy or even possible at this stage, where VM is
> > >>> running and we do not want to loose it.
> > 
> > We can check VDSM caps in late setup / customization and abort if cluster
> > compatibility is not 3.4.
> > I'm not sure that VDSM 3.3 is enough for running hosted engine.
> > 
> > We can warn the user about the minimum version of oVirt engine that must be
> > installed inside the VM and
> > after that we can check oVirt engine cluster compatibility and refuse to
> > continue until the cluster
> > have a correct support level. This will require manual changes like
> > upgrading
> > the engine in the VM
> > or fix cluster compatibility level if we find an invalid value.
> > 
> If we can assist the user with fixing cluster compatibility level to avoid
> a malformed end result this is the solution I'd go with. In this way the
> user will always get a working setup, with the relevant information.
> ie- something like:

I think there are two different issues here.

> 
> Current engine settings does not support your vdsm version please select how
> you wish to proceed:
> (1) Manually upgrade vdsm

This (at least >= some minimum) can be checked quite early, and we can decide
to simply abort if not met. Then user can upgrade and run deploy again.

> (2) Lower cluster compatibility to support your installed vdsm
> (3) Abort
> 
> Option (2) should do a simple db update to make sure the user has a running
> setup.

Indeed.

There is also the option Sandro suggested: Increase cluster compatibility level.
This will have to be done by the user, at least if it requires upgrading the
engine inside the VM.
-- 
Didi