Description of problem: During VM Impot Wizard, if the RHV authentication fails, the Wizard will keep trying to authenticate against RHV with wrong credential, over and over until the operation is canceled by the user. To many wrong attempts in a short period time might lock the RHV user. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Run the VM Import Wizard the the UI 2.In the provider definition step, provide wrong username or password*. 3.Click "Check & Save" *using wrong username is recommended to prevent your rhv account for being blocked. Actual results: The wizard will keep trying to connect and be rejected by RHV. Expected results: The Wizard should display an error to the user, allowing him to fix the problem, and continue. Additional info: @Pioter - Do you need any additional information?
There has been a big batch of v2v related bugs moved to kubevirt plugin at once. We are working on them but due to capacity this did not make it last sprint.
This probably can't be solved by frontend, since you can kill the window and the CRs will still live and try to connect to the engine. @Piotr what do you think? Can we have some reasonable backoffs in kubevirt-vmware or max attempts?
@Filip, we need to propagate this info to the ui. Corresponding backend fix was merged some time ago: https://github.com/kubevirt/vm-import-operator/pull/310
@Piotr, I think this bug concerns kubevirt-vmware. Could we do something similar here as well?
@Filip, there are two ways to handle this in kubevirt-vmware. 1. we can delete secret which would prevent checks 2. Wait for 5mins and it would stop -> https://github.com/ManageIQ/manageiq-v2v-conversion_host/blob/41c79d7952a94b4a45cfca88c9373a55abfc3350/kubevirt-vmware/pkg/controller/ovirtprovider/ovirtprovider_controller.go#L30 Are you looking for any other way?
1. Not sure, if deleting the secret or V2VVmwares is a k8s friendly, but it could work. 2. Not sure how many times it would try to connect (we are trying to prevent locking the enginge). Can we just limit the number of retries to a few. And try again after some timeout.
Verified on CNV-2.5 (iib:18173). The Overall timeout for retries is 1 minutes. If only the password is wrong, it will try for 1 min (10 trials) - That still locks RHV! - So it seems we still have a problem. Moving to Verified as the attached fix was validated, however need to open another BZ to avoid RHV lock
Here's is the bug to fix the RHV lock issue - Bug 1887140
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 (OpenShift Virtualization 2.5.0 Images), 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/RHEA-2020:5127