Bug 1821259 - Clicking to view a newly created VM - one request returns 404. VM is displayed successfully.
Summary: Clicking to view a newly created VM - one request returns 404. VM is displaye...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.5.0
Assignee: Yaacov Zamir
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-06 12:27 UTC by Ruth Netser
Modified: 2020-07-13 17:25 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-13 17:25:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
vm creation screen (15.94 KB, image/png)
2020-04-06 12:27 UTC, Ruth Netser
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 5472 0 None closed Bug 1821259: Look for VMI list instead of VMI obj 2020-08-19 11:37:11 UTC
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:25:53 UTC

Description Ruth Netser 2020-04-06 12:27:55 UTC
Created attachment 1676577 [details]
vm creation screen

Description of problem:
After VM creation, when clicking to view the newly created VM, one of the requests return 404. 
The VM page is successfully displayed.

Version-Release number of selected component (if applicable):
4.4.0-rc.6
CNV 2.3

How reproducible:
100%

Steps to Reproduce:
(open browser dev console using F12)
1. From the UI, create a VM using the Wizard
2. Click on "See virtual machine details" on the "Successfully created virtual machine" screen.


Actual results:
One of the page requests return 404.


Expected results:
No errors.

Additional info:

See attached error

Comment 2 Tomas Jelinek 2020-04-06 12:33:57 UTC
since there is no user facing error or functionality gap, only an ugly stack trace in the logs, moving to 4.5

Comment 3 Tomas Jelinek 2020-04-06 12:34:38 UTC
@Nelly, FYI

Comment 4 Nelly Credi 2020-04-06 19:44:30 UTC
ack

Comment 5 Yaacov Zamir 2020-05-13 11:19:09 UTC
notes:
the 404 request is for the VMI [1], when the VM is just created ( or if it's not running ) we will not have a VMI.

Since we can not know if a VM has or has not a VMI at this stage, we test by queering a maybe missing VMI sounds OK,

[1] https://github.com/openshift/console/blob/master/frontend/packages/kubevirt-plugin/src/components/vms/vm-details-page.tsx#L92

@Tomas can we close it as not a bug ?

Comment 6 Tomas Jelinek 2020-05-13 11:30:50 UTC
well, we still show the stack what is ugly. If we can not swallow the error in this case, than I would close it as "cant fix" instead of "not a bug" since it is a bug we can not fix.

Comment 7 Yaacov Zamir 2020-05-13 11:43:26 UTC
@Tomas thanks, leaving open for now.

Comment 8 Filip Krepinsky 2020-05-18 11:41:20 UTC
This should be fixed in core console. There should be at least an option in co-fetch to suppress 404 errors. (FirehoseResource already has optional prop to use/infer from). Then it can be fixed in all resources which are optional consistently. Many of these unnecessary 404 errors  are found throughout the whole codebase and could be cleaned up a bit.

Comment 9 Yaacov Zamir 2020-05-18 13:33:44 UTC
> There should be at least an option in co-fetch to suppress 404 errors.

sounds useful to me

> This should be fixed in core console.

Filip, can you open a BZ on management-console ?

Comment 10 Filip Krepinsky 2020-05-18 14:42:16 UTC
done: https://bugzilla.redhat.com/show_bug.cgi?id=1836956

Comment 13 Radim Hrazdil 2020-05-20 12:34:12 UTC
Verified in console release-4.5 branch commit: 5994c64ee529b650bae348ef78ebc23dca8db5c5
No 404 responses observed when navigating to newly created VM

Comment 14 Samuel Padgett 2020-06-03 14:49:44 UTC
The console message is both accurate and harmless. It's not displayed to the user. We shouldn't be changing the logic to avoid such messages. In fact, I personally think it's *worse* to suppress the message because it makes debugging problems harder.

We should probably revert this change.

Comment 15 Samuel Padgett 2020-06-03 15:12:58 UTC
We should handle the failed promise in the code if we're not, which should avoid the stack trace. But we shouldn't switch to a list request.

Comment 16 Yaacov Zamir 2020-06-03 18:51:18 UTC
> The console message is both accurate and harmless. 

VMI is owned by VM, it is perfectly ok to have the option to a list of owned objects without getting a 404 response if the list is empty.
Without this change, each time the VM has an empty list of VMIs we get a 404 message.

In our case this is not accurate, for example, we will not get such a 404 message for a list of owned Pods if we state they are **optional**
In our case it can also be harmful, it can obscure a real problem in the logs with lots of false-positive 404 lines.

> we shouldn't switch to a list request.

IMHO Listing all owned objects instead of just the first one is an OK solution in our use case (even if max size for this list is currently one).

Comment 17 Samuel Padgett 2020-06-03 20:02:13 UTC
The reason for Firehose `optional` is to prevent an error screen from being displayed to the user on errors. `coFetch` doesn't do that, so it's not needed there.

When you say a 404 message, you mean specifically in the JS console, right? Not anything displayed to the user?

Are you handling the failed promise from `coFetch`? (If not, that's a bug imo.)

Comment 18 Samuel Padgett 2020-06-03 20:03:46 UTC
You would need to handle the failed promise regardless to be able to check for 404 errors vs. other errors that you want to surface to the user.

Comment 19 Yaacov Zamir 2020-06-03 20:37:53 UTC
> When you say a 404 message, you mean specifically in the JS console, right? Not anything displayed to the user?

Yes, the code path is valid, no error or un-handled promise in the code, and user is not notified, a VM not owning any VMIs is normal.

the only problem is that a user debugging some other problem will see false 404 responses for queering an obj we know may not exist.


> You would need to handle the failed promise regardless to be able to check for 404 errors vs. other errors that you want to surface to the user.

We do not have a failed promise. the code is fine with VM not having owned VMIs

Comment 20 Filip Krepinsky 2020-06-04 17:45:00 UTC
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1836956, it is not possible to handle logging of 404 errors with current implementation of Firehose.

Comment 21 errata-xmlrpc 2020-07-13 17:25:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2409


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