Bug 1897276

This behavior is known and standard in Kubernetes/OpenShift where users describe what they want and the controller tries to implement it.
In this case, the Provider CR is created and it's condition is Not Ready, because the credentials/fingerprint are wrong. The user can either delete or update the CR.

Doing validation in the Provider wizard is a post-beta topic and will be revisited, as the two options we've identified are unsatisfactory:

1. Implement the validation in the UI code. We want the UI to only be a presentation layer that discovers resources and has no intrinsic logic. This is k8s recommendation that simplifies the code maintenance.
2. Let the UI create the Provider CR transparently and report its status. The risk is that the page is context is lost (cache clear...) and that a orphaned Provider CR is left.

This is considered an RFE and will only be addressed post-beta. And it may not have a solution.
Dropping severity to medium as the product works as expected. Setting priority to medium as it's post-beta.

Vince, I'm assigning this to you, since there's some design involved.

We still don't have a satisfying solution for this. Moving to 2.2.0.

Notes from discussions elsewhere for context:

The proposed solution here requires some further investigation. The plan is that we want to remove the SHA1 field entirely, and instead have the UI load certificate details such as fingerprint, issuer, expiration, etc. based on the provider URL, display them and ask the user to confirm whether they trust them.

Unknowns here:
* How exactly can we load these certificate details? Presumably we'll need to do this from the Node.js server and expose a route there the UI can use to request it.
* How do we want to trigger this cert info fetch and where to show the confirmation? We could:
  (a) fetch the info as soon as the user has entered a provider URL, display the details in the form and have the user check a box to confirm trust before submitting the form
  (b) wait for the user to submit the form, close the modal and open a certificate trust confirmation modal that will load the details and ask Yes/No, and only create the provider CR on Yes.
  (c) something else?
* Which specific certificate details do we need to show, and how to lay them out

The following issue is tracking this RFE:
https://github.com/konveyor/forklift-ui/issues/833

The feature is implemented in two parts.

First is the forklift UI backend API addition to resolve certification fetching.
The second part handles changes to UI in order to display a certificate's fingerprint once a new provider hostname has been entered.
From that a confirmation would be expected from the user to acknowledge the certificate validation.

Upstream patch is addressing the UI part https://github.com/konveyor/forklift-ui/pull/845

Verified with MTV-2.3.0-30 / iib:178080, OCP-4.10, CNV-4.10.0-683

In MTV-UI VMware Provider page, as soon as we enter the vCenter host name or IP address the UI load verify certificate.

The previous fingerprint-SHA1 field is removed where user always have to manually enter the SHA-1.

Now, MTV-UI fetch the info and User gets a Certificate information and check a box to confirm trust before submitting the form
(a)Certificate information-Issuer, vCenter SHA-1 fingerprint and Expiration date
(b)Checkbox-I trust the authenticity of this certificate

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 (MTV 2.3.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-2022:1183