----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: "Yedidyah Bar David" <didi(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Yedidyah Bar David" <didi(a)redhat.com>, "Doron
Fediuck"
> <dfediuck(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
> >> To: "Yedidyah Bar David" <didi(a)redhat.com>
> >> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Jiri
Moskovcak"
> >> <jmoskovc(a)redhat.com>, "engine-devel"
> >> <engine-devel(a)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(a)redhat.com>
> >>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
> >>> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>,
"Jiri Moskovcak"
> >>> <jmoskovc(a)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(a)redhat.com>
> >>>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> >>>> Cc: "Yedidyah Bar David" <didi(a)redhat.com>,
"Jiri Moskovcak"
> >>>> <jmoskovc(a)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