Bug 1477589 - [RFE][Default Route] - Add exclamation mark next to host with no default route
[RFE][Default Route] - Add exclamation mark next to host with no default route
Status: POST
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network (Show other bugs)
4.2.0
x86_64 Linux
medium Severity medium (vote)
: ovirt-4.2.1
: ---
Assigned To: Ales Musil
Michael Burman
: FutureFeature
Depends On:
Blocks: 1200963
  Show dependency treegraph
 
Reported: 2017-08-02 08:29 EDT by Michael Burman
Modified: 2017-11-22 07:34 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2?
mburman: testing_plan_complete+
ylavi: planning_ack+
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 82805 master ABANDONED core: Add defaultRoute indicator to VDS 2017-11-21 02:58 EST
oVirt gerrit 82806 master ABANDONED webadmin: Add message to Host without default route 2017-11-21 06:03 EST
oVirt gerrit 84305 master POST webadmin: Add message to Host without default route 2017-11-21 06:03 EST

  None (edit)
Description Michael Burman 2017-08-02 08:29:25 EDT
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):
4.2.0-0.0.master.20170801164139.git9b399c8.el7.centos
Comment 1 Yaniv Kaul 2017-09-18 09:35:53 EDT
I don't think it's high.
We could do it via an Ansible running in cron job and inject an event if needed.
Comment 2 Dan Kenigsberg 2017-09-20 18:37:46 EDT
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.
Comment 3 Ales Musil 2017-10-09 06:13:56 EDT
Hi Michael,
in which places it should be displayed? Main host tab, Clusters -> Hosts or both?
Comment 4 Dan Kenigsberg 2017-10-09 14:33:43 EDT
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.
Comment 5 Ales Musil 2017-10-12 05:36:58 EDT
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.
Comment 6 Dan Kenigsberg 2017-10-12 07:24:21 EDT
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?
Comment 7 Ales Musil 2017-10-13 04:30:05 EDT
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.
Comment 8 Michael Burman 2017-10-15 03:50:11 EDT
(In reply to Ales Musil from comment #3)
> Hi Michael,
> in which places it should be displayed? Main host tab, Clusters -> Hosts or
> both?

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.
Comment 9 Ales Musil 2017-10-18 09:06:00 EDT
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?
Comment 10 Michael Burman 2017-10-18 10:08:02 EDT
(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.
Comment 11 Dan Kenigsberg 2017-10-24 04:30:08 EDT
(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.
Comment 12 Dan Kenigsberg 2017-10-24 04:35:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.