Bug 1849527

Summary:	[v2v] [api] VM import RHV to CNV importer should stop send requests to RHV if they are rejected because of wrong user/pass
Product:	Container Native Virtualization (CNV)	Reporter:	Amos Mastbaum <amastbau>
Component:	V2V	Assignee:	Moti Asayag <masayag>
Status:	CLOSED ERRATA	QA Contact:	Amos Mastbaum <amastbau>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.4.0	CC:	cnv-qe-bugs, dagur, danken, pelauter, pkliczew, pvauter
Target Milestone:	---	Flags:	amastbau: needinfo+
Target Release:	2.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	v2.4.0-18	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-28 19:10:33 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 Amos Mastbaum 2020-06-22 06:33:52 UTC

Description of problem:
when running VM import from RHV to CNV, if the provider's (RHV) credentials in the secret are rejected by the provider, the importer will keep trying and that might lock the user in RHV 



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


How reproducible:

Set RHV to lock a user after too many attempts.

Steps to Reproduce:
1.using the cli, create a secret with wrong password and than create the importer.


Actual results:

The Importer will keep trying to connect to RHV


Expected results:

The importer should not try again if the request is rejected with wrong user/password.

If this cannot be fix/changes,

**Need to add to the documentation a link to the RHV unlock user procedure.



Additional info:
The UI has similar  behavior after clicking "Check&Save".

Comment 1 Piotr Kliczewski 2020-06-22 14:55:41 UTC

We should fail the import if the credentials are not correct.

Comment 2 Dan Kenigsberg 2020-07-02 07:26:09 UTC

Amos, why is this report private? Unless it refers to private customer data or a security vulnerability, a bug report should be public.

Comment 3 Amos Mastbaum 2020-07-07 13:24:10 UTC

Verified api behavior only

Comment 6 errata-xmlrpc 2020-07-28 19:10:33 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/RHSA-2020:3194