Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1754789

Summary:	"Import Error" shows immediately after create vm from URL
Product:	OpenShift Container Platform	Reporter:	Guohua Ouyang <gouyang>
Component:	Console Kubevirt Plugin	Assignee:	Marek Libra <mlibra>
Status:	CLOSED ERRATA	QA Contact:	Nelly Credi <ncredi>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.2.0	CC:	aos-bugs, gouyang, mlibra, ncredi, rhrazdil
Target Milestone:	---
Target Release:	4.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-23 11:06:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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