Description of problem:
[Default Route] - Add warning or notify the admin that the host has no default route.
As it was decided to close and not fix BZ 1476804 it is very possible that users will found them self in a situations they have no default route on the host.
If we not blocking to set a non-mgmt network with default route while not being attached to any host, we will end up without default route on the host.
It is very important to have an indication about such case. Admin/user should be notified that the host/s have no default route.
Version-Release number of selected component (if applicable):
I don't think it's high.
We could do it via an Ansible running in cron job and inject an event if needed.
I think that Burman is looking for for an exclamation mark next to host with no default route, not a periodic alert. I find periodic alert disturbing, as hosts with no gateway and no default route are perfectly usable and reasonable to have.
in which places it should be displayed? Main host tab, Clusters -> Hosts or both?
Both. If a host has no fencing configuration an exclamation mark shows on both places. Hovering above it, gave the reason(s) for it (such as no fencing config) in the old UI. That the tooltip functionality seems to be currently broken, but I'd like to see it restored, and to include a warning about a host with no default route.
The tooltip is not broken but was replaced by status report only. Do we want to display additional message under status if something went wrong with host? This messages are currently in general host tab.
Yes, let's add this under "Action Items".
Do you know if there's a UX bug on how the exclamation shows on the cluster sub-tab (almost hidden by the separator)? Or why there is no hyperlink from the cluster sub-tab hosts to the host details?
The almost hidden exclamation mark will be resolved in the patch as well. But I am not sure about the link to host details. From my point of view it looks like it would be pretty complicated, but maybe someone from UX team can give us hints if it is worth the effort.
(In reply to Ales Musil from comment #3)
> Hi Michael,
> in which places it should be displayed? Main host tab, Clusters -> Hosts or
Hi, on both please, as Dan mentioned.
Currently the exclamation mark give no tooltip with no info explaining why the exclamation mark is there.
The only place we have the info of why is under 'Action Items' and i actually would like to see this info on the tooltip when hovering on top of the exclamation mark.
do we want show warning before we get reported configuration from host (e.g. on creation of new host)? Or is it suitable enough to get this warning after it gets reported?
(In reply to Ales Musil from comment #9)
> Hi Michael,
> do we want show warning before we get reported configuration from host (e.g.
> on creation of new host)? Or is it suitable enough to get this warning after
> it gets reported?
Good question, actually not sure, it can be nice.
Let's ask Dan, but if we decide that yes, then this warning should appear when adding new host that has no default route and when editing a non-mgmt network with default route role while still not attached to the host.
(In reply to Michael Burman from comment #10)
> (In reply to Ales Musil from comment #9)
> > Hi Michael,
> > do we want show warning before we get reported configuration from host (e.g.
> > on creation of new host)? Or is it suitable enough to get this warning after
> > it gets reported?
> Hi Ales,
> Good question, actually not sure, it can be nice.
> Let's ask Dan, but if we decide that yes, then this warning should appear
> when adding new host that has no default route and when editing a non-mgmt
> network with default route role while still not attached to the host.
I would not mix this idea with this bug. Let us limit this bug for raising a warning on existing hosts with no default route.
I is a nice idea to add the warning to HostSetupNetwork dialog, too, but I'm not sure where, as that dialog is already overcrowded with information.
It is better to warn the use only after we have the first getCaps in our hands, but I can live with a temporary warning that would go away quickly.
There's a way to work around this issue ?
I'm almost sure that in a HC gluster deploy, this happen only where host 2 and 3 are imported.
I'm using ovirt-node-ng 20171215 rc3 image to install hosts.
(In reply to Roberto N from comment #13)
> There's a way to work around this issue ?
> I'm almost sure that in a HC gluster deploy, this happen only where host 2
> and 3 are imported.
> I'm using ovirt-node-ng 20171215 rc3 image to install hosts.
The issue is currently was caused by this fix and already has a patch that fix it as well.
This message will appear only for hosts that has no default route on the host.
BTW - It's an engine bug and not vdsm, so the fix will be on the engine side and not the node side.
We decided to assign this bug back as some small gap still exist when 3.6 host running in the engine.
The UI will report that this host has no default route on the host.
The notification/exclamation mark should show up only on clusterLevel >= 4.1
I am wondering if this is fixed. When trying with ovirt 4.2 I hit this bug and VMs were refusing to migrate at the affected host.
this warning is only displayed in UI and should not affect migration at all.
For the migration problem please send email to users or open new bug report and add vdsm.log, supervdsm.log from the host and engine.log.
I erroneously linked this behaviour with this issue.
I was able at some point to live migrate.
I will update from 4.2.0 to 4.2.1 to see if this issue is fixed.
Verified on - 4.2.2-0.1.el7
Scenarios tested -
- Clusters > Logical Networks flow - PASS
- Logical Networks > Cluster flow - PASS
- Add host with default route - PASS
- Add host without default route - PASS
- Add 3.6 host to cluster 3.6 - PASS
Exclamation mark will be only reported and disblayed for hosts that report default route property, which means 4.1=< only.
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.
Since the problem described in this bug report should be
resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE.
If the solution does not work for you, please open a new bug report.