make hidden errors more obvious

[jelkosz]

There are situations when the start of the VM is not successful (such as permission denied on the disk it is using) but the VM is still "running" from kubevirt point of view, only the OS inside is stuck. This is surfaced in the events of the VM but if the unsuspecting user does not deliberately go to the events to check them, everything looks good.
It would be good to warn the user in this situations.

Some limitations which come to mind:

• it needs to fit well with the rest of openshift - we can not invent something completely new which will not be accepted by upstream
• need to make sure we do not flood the user with errors of VMs of other users (as we do in oVirt ;) )
• if something breaks in the infrastructure itself, all the VMs will get into troubles. Need to make sure we are not flooding the screen in this case because the user will be more annoyed than thankful

@lizsurette what do you think?

[ohadlevy]

can we list those errors? or instead, have a flow when starting up in which we can track overall status and associate messages to each step ? (success / failures)

…

On Thu, Nov 1, 2018 at 9:42 AM Tomas Jelinek ***@***.***> wrote: There are situations when the start of the VM is not successful (such as permission denied on the disk it is using) but the VM is still "running" from kubevirt point of view, only the OS inside is stuck. This is surfaced in the events of the VM but if the unsuspecting user does not deliberately go to the events to check them, everything looks good. It would be good to warn the user in this situations. Some limitations which come to mind: - it needs to fit well with the rest of openshift - we can not invent something completely new which will not be accepted by upstream - need to make sure we do not flood the user with errors of VMs of other users (as we do in oVirt ;) ) - if something breaks in the infrastructure itself, all the VMs will get into troubles. Need to make sure we are not flooding the screen in this case because the user will be more annoyed than thankful @lizsurette <https://github.com/lizsurette> what do you think? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#77>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOx5vE_Y38urOcPUvHNDtskh0ai_AMks5uqqX2gaJpZM4YF7nv> .

[jelkosz]

can we list those errors?

we don't. We've hit it once and Im sure we will hit it again. So it is a good time to start the discussion in conceptual level how to handle such cases.

or instead, have a flow when starting up in which we can track overall status and associate messages to each step ? (success / failures)

that we potentially could, just the question is how to visualize when we find out it failed.

[rawagner]

The error I experienced (incorrect permission on disk.img in PV) was just a warning severity event from one of kubevirts pods (controller/launcher..i dont remember exactly). So we will need to visualize every event which has severity >= warning

[lizsurette]

I don't think this is the place to track it, but I wanted to say that I think it would be awesome to first attempt to be proactive and help the user avoid hitting some of these warning/error cases when possible. In @rawagner 's scenario. Rather than warn the user about permission issues after creating the VM, is there any way we can put a permission check in when the user is selecting a disk? Or maybe even avoid listing any PVC's that they don't have access to? Ultimately, could we do our best to not allow the user to hit some of the issues that we know about?

So to the point of this issue ( :) ) I wonder if we should introduce some sort of "Degraded" status that is shown in the VM table where technically the VM is running, but it might not be fully featured (for example if you can't use all of the disks or you can't access the console):

Along with adding this status with more information in the table, I think a toast notification would help draw attention to the issue. The details should remain in the Events tab of the VM Details, too, IMO.

What do you all think? I'd be interested in what @andybraren and @matthewcarleton think too :)

[andybraren]

@lizsurette This looks good to me, and to my knowledge is consistent with how errors are currently handled in OpenShift.

Since multiple non-breaking errors could theoretically occur at the same time, the icon popover text might need to generically point the user to the VM's Events tab for more information. The generic-ness of the toast notification looks perfect, and I imagine would bring the user to the same Events tab when clicked. Nice 👍.

I suppose "Degraded" would be lumped under the "Error" filter we have in the VM List View? I can update our VM List View doc with an example of this kind of warning.

[lizsurette]

Since multiple non-breaking errors could theoretically occur at the same time, the icon popover text might need to generically point the user to the VM's Events tab for more information.

Great point! Or maybe it can scale to include multiple issues.

I imagine would bring the user to the same Events tab when clicked.

Yes. Thanks for calling this out.

I suppose "Degraded" would be lumped under the "Error" filter we have in the VM List View? I can update our VM List View doc with an example of this kind of warning.

+1. If others here are happy with this as a solution we should update.

[mareklibra]

@lizsurette , @andybraren , so the 'Status' column will depict the value using icons? It's text recently.
The icon will have tooltip with a short message.
A failure-icon will be click-able to lead the user to the VM Events page.

[mareklibra]

What about State field on the Overview page? I feel text (Running, Starting, Failure, Stopped) fits better here.

[andybraren]

@mareklibra You're right, status icons should be paired with a label in both the table's Status column and within the Status field of the VM's Overview page. OpenShift's documentation for the status column is here.

Below is an updated example of our status column design. Hovering over either the warning icon or label should display the tooltip with slightly more detail about the issue. Clicking either the warning icon or its label should bring the user to the VM's Events page.

[andybraren]

I've updated our VM List documentation with the above.