----- Original Message ----- > From: "Doron Fediuck" <dfedi...@redhat.com> > To: "Sandro Bonazzola" <sbona...@redhat.com> > Cc: "Yedidyah Bar David" <d...@redhat.com>, "engine-devel" > <engine-devel@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" <sbona...@redhat.com> > > To: "Yedidyah Bar David" <d...@redhat.com>, "Doron Fediuck" > > <dfedi...@redhat.com> > > Cc: "engine-devel" <engine-devel@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" <dfedi...@redhat.com> > > >> To: "Yedidyah Bar David" <d...@redhat.com> > > >> Cc: "Sandro Bonazzola" <sbona...@redhat.com>, "Jiri Moskovcak" > > >> <jmosk...@redhat.com>, "engine-devel" > > >> <engine-devel@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" <d...@redhat.com> > > >>> To: "Doron Fediuck" <dfedi...@redhat.com> > > >>> Cc: "Sandro Bonazzola" <sbona...@redhat.com>, "Jiri Moskovcak" > > >>> <jmosk...@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" <dfedi...@redhat.com> > > >>>> To: "Sandro Bonazzola" <sbona...@redhat.com> > > >>>> Cc: "Yedidyah Bar David" <d...@redhat.com>, "Jiri Moskovcak" > > >>>> <jmosk...@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 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
