Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
5:47 a.m.
----- 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.
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.
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
5:59 a.m.
New subject: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
----- 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.
>
> 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
>
--
Didi
2:11 a.m.
New subject: [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.
>>
>> 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
3:08 a.m.
New subject: [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:
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
3:13 a.m.
New subject: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
----- 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
3:15 a.m.
New subject: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
Il 17/03/2014 09:08, Doron Fediuck ha scritto:
----- 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:
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?
We should also consider the case with VDSM having 3.4 compatibility and engine missing it
(wrong version installed)
(1) Manually upgrade ovirt-engine
as alternative to
(1) Manually upgrade vdsm
>
>>>>
>>>> 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
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
3:21 a.m.
New subject: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
>>>>>> 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.
BTW, no-one addressed the original point in the bug.
We might solve the specific compatibility level issue, but the general
question still remains: Should the engine treat differently the VM and host
that are running itself? Knowing that killing them means committing suicide
(or, in other words, probably require manual cli action from the user)?
--
Didi
3:37 a.m.
New subject: [Engine-devel] 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: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Monday, March 17, 2014 10:21:39 AM
Subject: Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the
VM with the hosted engine
> >>>>>> 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.
BTW, no-one addressed the original point in the bug.
We might solve the specific compatibility level issue, but the general
question still remains: Should the engine treat differently the VM and host
that are running itself? Knowing that killing them means committing suicide
(or, in other words, probably require manual cli action from the user)?
This is what I'm trying to avoid. It is possible but will add special logic
we should try to avoid. If the setup makes sure you have a running deployment
you can leave it as is. the user will always be able to do bad things in the
system and we should not nanny them, as long as they are aware of what they do.
--
Didi
3716
days inactive
3717
days old
7 comments
3 participants
participants (3)
-
Doron Fediuck -
Sandro Bonazzola -
Yedidyah Bar David