Bug 1754789 - "Import Error" shows immediately after create vm from URL
Summary: "Import Error" shows immediately after create vm from URL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.3.0
Assignee: Marek Libra
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-24 05:48 UTC by Guohua Ouyang
Modified: 2020-01-23 11:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The VMware import starts in an error-state Consequence: Bad user experience caused by confusing reporting of the state. Fix: The state of import is reported as Pending if the conversion pod is not running but waiting to be scheduled. Result: The user sees Pending state when the conversion is not yet started.
Clone Of:
Environment:
Last Closed: 2020-01-23 11:06:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 3354 0 'None' closed Bug 1754789: Fix pending status of the importer pod 2020-03-17 09:53:22 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:07:14 UTC

Description Guohua Ouyang 2019-09-24 05:48:38 UTC
Description of problem:
Creates a VM from URL via wizard(don't use template), after the vm is created, "Import Error" shows immediately, and then it becomes "Importing". If "Start virtual machine on creation" is ticked, the status will come "Starting" -> "Running".

Version-Release number of selected component (if applicable):
4.2.0-0.nightly-2019-09-21-183303

How reproducible:
100%

Steps to Reproduce:
1. Open create from wizard
2. Use URL as the source
3. Create the vm
 
Actual results:
"Import Error" shows immediately.

Expected results:
No such status shows.

Additional info:

Comment 1 Marek Libra 2019-11-07 13:50:15 UTC
The status originates most probably from the case when the importer pod is not schedulable because of pending PVC claim.
The status is determined based on the conditions.

The pod status section looks like:
```
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2019-11-06T09:18:43Z
    message: pod has unbound immediate PersistentVolumeClaims (repeated 4 times)
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
```

We should take the "phase" into consideration.

Comment 2 Guohua Ouyang 2019-11-08 05:08:57 UTC
Hi Marek,
This issues is also seeing in 1.4? do we need to fix it in 1.4?

Comment 3 Guohua Ouyang 2019-11-08 05:10:33 UTC
Nelly, could you give an answer to c#2 as well?

Comment 4 Marek Libra 2019-11-08 09:00:48 UTC
Unfortunately, I do not have access to any 1.4 environment to try.

In any case, I believe that impact of this issue is very low. It's just annoying from my perspective.

Comment 5 Guohua Ouyang 2019-11-08 09:18:26 UTC
I agree the impact is low as the VM can get into 'running' eventually.
Let's waiting for Nelly's inputs.

Comment 6 Nelly Credi 2019-11-10 13:01:00 UTC
I think this is low for 1.4,
but for 2.2.0 we should get it fixed, 
this is a very bad customer experience

Comment 8 Radim Hrazdil 2019-11-28 09:49:03 UTC
Verified that this issue doesn't occur.
4.3.0-0.nightly-2019-11-21-122827

Comment 10 errata-xmlrpc 2020-01-23 11:06:54 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:0062


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