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&gt; > To: "Yedidyah Bar David" <didi(a)redhat.com&gt;, "Doron Fediuck" <dfediuck(a)redhat.com&gt; > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; > 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&gt; >>> To: "Yedidyah Bar David" <didi(a)redhat.com&gt; >>> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt;, "Jiri Moskovcak" >>> <jmoskovc(a)redhat.com&gt;, "engine-devel" >>> <engine-devel(a)ovirt.org&gt; >>> 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&gt; >>>> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>>> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt;, "Jiri Moskovcak" >>>> <jmoskovc(a)redhat.com&gt; >>>> 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&gt; >>>>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; >>>>> Cc: "Yedidyah Bar David" <didi(a)redhat.com&gt;, "Jiri Moskovcak" >>>>> <jmoskovc(a)redhat.com&gt; >>>>> 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: Current engine settings does not support your vdsm version please select how you wish to proceed: (1) Manually upgrade vdsm (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. Thoughts?

> >>>> >>>> Thinking about this again, I am not sure the current behavior is that >>>> bad. "Fixing" by re-installing with the correct versions is probably >>>> way simpler than fixing after installation is (mostly) complete. >>>> >>>>> >>>>> I'm not keen on adding hosted-engine logic into the engine code. >>>> >>>> Not sure about that. Not that it would help much, because the root >>>> problem will still have to be solved, but in principle it might be >>>> a good thing if the engine knows that killing some host will kill itself, >>>> and so try harder to not do that and just leave it in some zombie, >>>> requires-manual-action state. This is obviously more important during >>>> normal operation than during installation. >>>> -- >>>> Didi >>>> >>> >> > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >