Created attachment 1474707 [details] running vm Description of problem: If one stops a running VM in the Web Console, it shows Failed State and then switches to Unknown. However, `oc describe vms <vm_name>` shows a successful delete in Events logs. Version-Release number of selected component (if applicable): OS 3.10.27 How reproducible: always Steps to Reproduce: 1. create a VM 2. start it 3. stop it in the web console Actual results: see attachments Expected results: `State: Scheduling` like for the Start operation, and then changed for `Stopped` or "Offline"
Created attachment 1474708 [details] State: Failed
Created attachment 1474709 [details] State: Unknown
In fact, any created VM will have "State: Unknown" in the Web Console if it wasn't started. I expect to be "Offline" or "Not Running", but not "Unknown"
Fixed by: https://github.com/kubevirt/origin-web-console/pull/7
Included in origin-web-console:1.1-4
It's showing "not running" when the VM is stopped and "scheduling" when start a VM, then it become "running" when the VM is started. When stop/restart a VM, "Failed" state is still can be seen. Is it the expected behavior?
I wouldn't expect "Failed" ton stop/restart. "offline", "stopped", smth similar is ok but not "failed".
The value reflects VMI "phase" from API which is "Failed" at this moment. The user gets same information when checking state via command-line. I don't think we should deviate from the command-line.
It's true that VMI state is "Failed" when stop/restart it. I would accept it at the moment. @irina, What do you think?
@Guohua, sorry, I didn't reply sooner. To me and I bet to you "Failed" means that smth is wrong, smth is not working properly. I wouldn't accept it as an indicator of a successful Stopped/Restarted status. What if there is really an error, and VM wasn't stopped/restarted for some reason? How to distinguish this real "Failed" situation with a "Failed" status which is displayed now? Also mind that the QA tests are supposed to accept "Failed" instead of "Success", again if smth is really wrong we may never know. @Marek, if 'Failed' comes from API, it's an issue of API then, and it should be filed and resolved accordingly. I would open a new BZ on API, returned this one to Assigned and linked them like blocked/depends on. Thoughts?
There are a few PR on github about the "failed" state: https://github.com/kubevirt/kubevirt/issues/1137 https://github.com/kubevirt/kubevirt/pull/1212 https://github.com/kubevirt/kubevirt/pull/1233 https://github.com/kubevirt/kubevirt/pull/1389 @Roman, could you give an input on this? The situation is when stop/restart a VM from web console or cli, "Failed" state is still can be seen.
It is righ now pretty easy in kubevirt to run into a failed state. For instance if you have a too low grace period or if you don't have acpi set on a VMI. We will have to improve that over time and look into the individual cases where the VMI reported failed and why. One word in general: I think that it is not appropriate for a VM to show succeeded or failed if the VMI does not exist. I consider it a mistake to have a status field which copies the VMI state. a VMI can disappear any moment and then the VM has no reference to look at to determine a proper state if it misses the delete event. The VM view should determine the actual state from a VMI object, if it exists. If it does not exist, it can show "down" or "shutoff". If the last VMI run was successful or not will only be consistently visible in the event log if the corresponding VMI is gone. As far as I know the openshift ui uses the event log on many places to show errors. Our UI components should work the same way. I hope that helps.
Let me add here, that we can change VM-VMI relationship in a way that we can block the VMI disappearence until the VM controller had time to collect a final state (with a finalizer). Maybe that is the right approach. Marek what do you think?
Roman, that would help. The "failing" state is just temporary. The idea is to reflect current state without tweaking it with runtime data (like knowledge what actions has been issued). Event/log analyzes might be still a way to tune corner or transitional states but it would complicate things. The user should get consistent information, no matter if he is in GUI or on cmd line.
@Roman, it indeed makes sense. Thanks.
@Irina @Marek can we close this bug now?
we have agreed to close it as 'wontfix' From Tomas: it is not a bug on UI, we only show what the API returns us. This is true for the old UI and will be true for the new one. As Roman suggested, it might make sense to go over the failed cases one by one and to investigate/fix on kubevirt side to not to report the VM as failed. But if it is reported as failed, I don't think UI should show anything else.