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

Bug 1965326

Summary:	Add Provider validations to avoid a migration plan running with no progress and no exposed reason
Product:	Migration Toolkit for Virtualization	Reporter:	Ilanit Stein <istein>
Component:	General	Assignee:	Arik <ahadas>
Status:	CLOSED MIGRATED	QA Contact:	Ilanit Stein <istein>
Severity:	medium	Docs Contact:	Avital Pinnick <apinnick>
Priority:	medium
Version:	2.0.0	CC:	ahadas, apinnick, fdupont, istein, jortel, joschrod
Target Milestone:	---
Target Release:	Future
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-01-02 17:10:26 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 Ilanit Stein 2021-05-27 13:12:58 UTC

Description of problem:
There are cases that the migration plan is pending something and not progressing, without any reason displayed. 
The plan is displayed as "running" and the VMs in the plan are displayed in "Transfer Disk" stage, though this stage was never reached.

Jeff Ortel: 
"Seems like we should add validations to the provider to:
1. Ensure CNV is installed
2. Ensure the vddk image is installed.
3. …,
The validation (failure) would result in critical conditions which would prevent the provider from being READY which will block migrations.
This seems better than adding a non-VM-specific validation step to the VM pipeline which would result in the same testing being run (over and over) and failing each VM."

Version-Release number of selected component (if applicable):
MTV-2.0.0

Additional info:
Would be good to include here this validation too: 
Ensure required storage is available, if possible.
CDI importer DataVolume reports "pending" in such a case.

Comment 1 Fabien Dupont 2021-10-11 10:03:53 UTC

The requirement has changed. We only want to verify that the APIs we need in the destination cluster are available.

Comment 2 Sam Lucidi 2021-10-26 20:09:57 UTC

https://bugzilla.redhat.com/show_bug.cgi?id=1965326

Comment 3 Sam Lucidi 2021-10-26 20:10:33 UTC

https://github.com/konveyor/forklift-controller/pull/379

Comment 4 Sam Lucidi 2021-10-27 18:12:14 UTC

Moving back to assigned, as the above PR is inadequate. Because the Provider controller can't watch the CRDs on a remote cluster, the error condition will not be cleared if the missing dependencies are installed. Mitigating that would require using the inventory to collect CRDs so that the Provider could be notified when they change, but that runs into a chicken-and-egg problem with the provider's inventory. I think this is too complex to solve correctly in 2.2, and it would be better to address it in 2.3. Fabien, what do you think?

Comment 5 Arik 2023-01-02 17:10:03 UTC

I don't think it's so likely to happen in the field but when it does, we can just point out that the target cluster is not set properly and fail the request to add the provider