Description of problem:
In 4.0.5 one can deploy a host with command line and also from within the gui.
If the gui option becomes the default and preferred way to deploy hosts in self hosted engine environments, I think it should be put in clearer shape that if you follow the default action you would not have high availability for the hosted engine vm.
Or changing the default action to "Deploy", or showing a popup if the hosted engine vm has only one host configured for it but there are other hosts in the cluster.
Default now is currently none:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. oVirt 4.0.5 with self hoste engine
2. deploy a host from the gui
3. by default the host IS NOT hosted engine enabled
If you follow default steps, you would not have HA for the self hosted engine...
The user should be proposed in deploy host steps that he/she has currently not HA for hosted engine VM if only one host inside the cluster is configured as Hosted Engine enabled
Thanks for reporting.
This is actually relevant even if you have more than a single host installed,
but for some reason only a single host is available. In both cases the user should be warned.
In ovirt manual page only the command line method is described to add more hosts:
And I presume that indeed it will add a host as a self-hosted engine host.
But in ovirt users mailing list I understood that the web admin method will become the default one.
And in fact I see now that the official RHEV guide contains only that method and not the command line one:
Indeed the guide has the information that if you want HA for the engine VM you have to add more self-hosted engine hosts and that you have to select "Deploy" radio button.
My concern is that this could be overlooked and user could add many hosts being sure to already have HA for the engine VM when it is not true if he/she doesn't manually select "Deploy" option inside the relevant sub-tab.
What could be the cons of having "Deploy" as the default option?
We have all in one use cases where we only have a single node with a single HE agent to conserve HW. Therefore I do not want to add this type of warning, it could be a valid arch.
(In reply to Yaniv Lavi from comment #3)
> We have all in one use cases where we only have a single node with a single
> HE agent to conserve HW.
> Therefore I do not want to add this type of
> warning, it could be a valid arch.
Not sure about that. In certain flows we do assume that there is more than one host, or that one host can be moved to maintenance, etc. - e.g. backup/restore.
Generally speaking, although hosted-engine on a single host does work, it's not our recommended setup. We used to have an allinone plugin that allowed running the engine directly on a host (not in a vm), and we still maintain it inside ovirt-live. It was removed in 4.0 iirc with the assumption that hosted-engine replaces it. I do not think it fully does, so far. There are also issues with NFS/iSCSI on same machine.
So if we want to fully support hosted-engine on a single host, we have some work to do. If we don't, might as well warn, suggesting to add more hosts.
Actually I had two points in my bug opening considerations:
1) configure Deploy as the default option
the user has to manually set it as non-hosted engine enabled
2) in case 1) not accepted, at least warn the user if only one host is of kind hosted engine enabled.
I think you can issue a command that can get the number of hosts inside the cluster. In case this number > 1 than raise the warning, otherwise do nothing.
I prefer 1 warning more, than user disappointed when he/she thinks to have hosted-engine VM high available by default, but indeed this is not true and the acknowledge is gotten via downtime...
(In reply to Yedidyah Bar David from comment #4)
> Generally speaking, although hosted-engine on a single host does work, it's
> not our recommended setup. We used to have an allinone plugin that allowed
> running the engine directly on a host (not in a vm), and we still maintain
> it inside ovirt-live. It was removed in 4.0 iirc with the assumption that
> hosted-engine replaces it. I do not think it fully does, so far. There are
> also issues with NFS/iSCSI on same machine.
The use case is with Gluster exposing the local storage.
(In reply to Gianluca Cecchi from comment #5)
> I prefer 1 warning more, than user disappointed when he/she thinks to have
> hosted-engine VM high available by default, but indeed this is not true and
> the acknowledge is gotten via downtime...
We added a mark for the HE hosts in the UI. You should be able to see there only one host.
Again a warning means something is wrong, but in some cases, it's not.
In any case deploying the HE host is a day one operation, so I don't expect the user to only deploy one by mistake.