Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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
Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com>, "Doron Fediuck" <dfediuck@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" <dfediuck@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@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" <sbonazzo@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com>, "Doron Fediuck" <dfediuck@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" <dfediuck@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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
Il 17/03/2014 09:08, Doron Fediuck ha scritto:
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com>, "Doron Fediuck" <dfediuck@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" <dfediuck@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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" <didi@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Jiri Moskovcak" <jmoskovc@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@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
> 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
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "engine-devel" <engine-devel@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
participants (3)
-
Doron Fediuck -
Sandro Bonazzola -
Yedidyah Bar David