Bug 1287725
| Summary: | [Webadmin] Error message appears when failing to change host cluster compatibility version | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Nikolai Sednev <nsednev> | ||||||
| Component: | Frontend.WebAdmin | Assignee: | Alexander Wels <awels> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Pavel Stehlik <pstehlik> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 3.6.1.2 | CC: | bugs, ecohen, gklein, nsednev, oourfali | ||||||
| Target Milestone: | ovirt-3.6.2 | Keywords: | Regression | ||||||
| Target Release: | --- | Flags: | oourfali:
ovirt-3.6.z?
rule-engine: blocker? rule-engine: planning_ack? nsednev: devel_ack? rule-engine: testing_ack? |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | infra | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-12-14 19:45:21 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Nikolai Sednev
2015-12-02 14:30:44 UTC
Created attachment 1101512 [details]
Screenshot from 2015-12-02 16:26:19.png
Created attachment 1101516 [details]
engine and server logs
This also happens on clean 3.6.1, so no direct relation to upgrade. This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Why is this a regression? did you get to the same scenario, after hitting bug 1287136 , in previous releases? Reducing to medium severity. (In reply to Yaniv Kaul from comment #5) > Why is this a regression? did you get to the same scenario, after hitting > bug 1287136 , in previous releases? > > Reducing to medium severity. As far as I know, recently the UX guys added an ability to see UX errors in the UI. So, even if things work properly, and there is some UI exception, it will show there. It is important, however, until we clear all of those, I think we might want to have this feature turned off, so that we will use it here in QE and DEV, but not for customers. Einav - thoughts? Perhaps I'm wrong, but I've noticed that only recently. @Oved, Yes its a new addition to 3.6. All it does is make an uncaught exception visible in the UI, to alert the user something is wrong. Before it would just break and the user would be none the wiser. The exception would be in the browser console, but since almost no one looks there it was never reported. This encourages people to report so we can investigate and fix whatever issue caused the uncaught exception. We even provide a mapping file so we can look up what the obfuscated variables/classes are in the exception. I would have to look at the patch, but I don't think we can turn it off selectively for customers vs qa. @Nikolai, Can you give me access to the system so I can see the reproduction steps in action? This will help me figure out what is going on. +1 to Alexander's comment.
for everyone (dev, QA, users, customers) it is better to display these alerts:
- it encourages the user to report the problem.
- it suggests a temporary solution ("Please try reloading the page") in order to workaround any potential unexpected behaviors due to javascripts that stopped working.
disabling these alerts would mean, obviously - potential unexpected behaviors due to javascripts that stopped working (e.g. things like infinite loading animations as originally reported in bug 1284584, etc.), which IMO is a worse choice than keeping these alerts.
(In reply to Einav Cohen from comment #8) > +1 to Alexander's comment. > > for everyone (dev, QA, users, customers) it is better to display these > alerts: > - it encourages the user to report the problem. > - it suggests a temporary solution ("Please try reloading the page") in > order to workaround any potential unexpected behaviors due to javascripts > that stopped working. > > disabling these alerts would mean, obviously - potential unexpected > behaviors due to javascripts that stopped working (e.g. things like infinite > loading animations as originally reported in bug 1284584, etc.), which IMO > is a worse choice than keeping these alerts. I don't have any disagreement in this, just reporting it as a bug as it should not happen, we need to find out the root cause of this problem, so I attached all logs I thought you'd need and provided you with the access to environment. Indeed a great addition. I didn't mean to say that we should remove that. However, we should make sure to indeed cover every issue we see first. As some of those might have no impact, but might be a bit scary for users. So, if we feel that we're stable with regards to that, then it should indeed be operating everywhere. I just happen to see that today in the same dialog, but everything worked properly with the dialog, but that might not be the common case. I was trying to reproduce this issue, while following these steps and failed, the issue not always reproducible, is there anything useful within the logs? Unfortunately the logs are all on the backend side while the actual problem is on the frontend side which has little to no information to tell us what is wrong. We just implemented some functionality to give us some indication there is a problem in the frontend (the popup with the uncaught exception message). Most likely what is happening, is some somewhat unusual condition happens, which in the end causes some null pointer exception within the UI code. Its just a matter of finding the right steps to reproduce. My main question is. Are the steps I did above what you did to produce the original problem, or is did you do something else? From the original bug report it was not entirely clear to me what the steps are to reproducing the problem. So I took what was there and tried to make some easy to follow steps from them but was unable to reproduce at that point. TL;DR I am trying to find some reproducer steps. Obviously the ones I tried didn't work, did I follow the same ones you did? (In reply to Alexander Wels from comment #14) > Unfortunately the logs are all on the backend side while the actual problem > is on the frontend side which has little to no information to tell us what > is wrong. We just implemented some functionality to give us some indication > there is a problem in the frontend (the popup with the uncaught exception > message). > > Most likely what is happening, is some somewhat unusual condition happens, > which in the end causes some null pointer exception within the UI code. Its > just a matter of finding the right steps to reproduce. > > My main question is. Are the steps I did above what you did to produce the > original problem, or is did you do something else? From the original bug > report it was not entirely clear to me what the steps are to reproducing the > problem. So I took what was there and tried to make some easy to follow > steps from them but was unable to reproduce at that point. > > TL;DR > I am trying to find some reproducer steps. Obviously the ones I tried didn't > work, did I follow the same ones you did? Yes, you've followed exactly the same steps, but again I'm too was unable to reproduce this issue, while was following the same steps a few days ago. I did exactly the same steps as you did, but unfortunately not always saw this WEBUI problem, now for example I see this issue while creating template from VM and then creating VMs from the template, this issue being reproduced occasionally and there are few more other flows which lead to this issue, some QA engineers saw the same error while were adding or deleting storage domains or trying to edit VMs. Okay so when you see that message in different places the problem is somewhere in whatever flow you are working with. When you hover over the exception message it will show you a stack trace of obfuscated code. You will also see that stack trace in the browser console. The important part for us is that stack trace. Together with the symbolMap package we can piece together which part of the source code is causing the exception. So when you say some QE engineers saw that exception during adding/deleting storage domains. That is actually two separate problems in the code and should be reported as two separate bugs. The same with issues creating VMs from templates. So please when you see that exception check the browser console and copy and paste the stack trace into a new bug. Also give detailed steps on how to reproduce for when we ask access to the system so we can reproduce. (In reply to Alexander Wels from comment #16) > Okay so when you see that message in different places the problem is > somewhere in whatever flow you are working with. When you hover over the > exception message it will show you a stack trace of obfuscated code. You > will also see that stack trace in the browser console. > > The important part for us is that stack trace. Together with the symbolMap > package we can piece together which part of the source code is causing the > exception. > > So when you say some QE engineers saw that exception during adding/deleting > storage domains. That is actually two separate problems in the code and > should be reported as two separate bugs. The same with issues creating VMs > from templates. > > So please when you see that exception check the browser console and copy and > paste the stack trace into a new bug. Also give detailed steps on how to > reproduce for when we ask access to the system so we can reproduce. The reproduction steps were fine, it's not reproduced any more using these steps, but once it was possible to get the reproduction using exactly the same steps. If there is nothing else the attached logs can provide you with, please close this bug as missing information or works for me. (In reply to Nikolai Sednev from comment #17) > If there is nothing else the attached logs can provide you with, please > close this bug as missing information or works for me. closing on works-for-me; please feel free to re-open if you have the relevant client (javascript) logs (specifically - we are looking for the full javascript exception stacktrace). The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |