As a user I want to be notified ASAP in the OSD or Rosa wizards if there is an error with my network configuration.   

Implementation Details

The 'on demand' network verifier OCM APIs can be run at any time (not just as part of installer 'in-flight' checks).

The first POST API kicks off the network verifications on the provided payload which contains 'region' and a list of 'subnets' to validate:
POST ​/api​/clusters_mgmt​/v1​/network_verifications

The subsequent GET API calls with the `subnet_verification_id` returns status of the network verification test:
GET /api/clusters_mgmt/v1/network_verifications/<subnet_verification_id>

• UI will need to periodically poll for each subnet until all return pass or fail.

Design Doc: OSD/ROSA network-verifier  Option 1 which shows these checks as 'pre-flight' ('On demand' is the term prefered by the backend team). 

Open Issues

UX

1. There is a question on whether we could do the validation earlier in the wizard, when user has selected/specified the subnets?  Would need new mockups around how to display this upon a "Next" wizard button click.
2. The 'pre-flight/on-demand' mockups need to be updated, they no longer match the backend API data/statuses.  it should be a list of the subnets, each row has subnet id and status of running, passed, failed.   
3. When all subnets are no longer 'running' (pending) and each returned a status of passed or failed, then If there is at least one subnet failure, we need to show the failure message to the end user, and prevent then from going to the next wizard step or to cluster creation submission.

Backend

1. (resolved) the payload for the POST command includes `aws.account_id` & `aws.access_key_id` & `aws.secret_access_key`.  The user does enter these credentials as part of the OSD -> CCS -> AWS flow, however the user doesn't enter these credentials for the Rosa Wizard.   
   wkutler@redhat.com wrote: The payload for the (rosa) POST request only needs the STS role. If other credentials are supplied they’ll be overwritten by the credentials from assuming the role. Sorry for the confusion (edited)
2. (resolved) If we implement this 'on-demand' network verifier check in the UI, will it also run again as part of the 'in-flight' cluster creation tests?  So, in a sense it gets run twice in the UI flow (pre/on-demand & in-flight)?
   rh-ee-gbranco wrote:  Yes, it runs as part of the inflights as well. There isn't a way to specify to skip. I believe the idea is that the customer might still change some setting even though he just passed the on demand

Acceptance Criteria

Resources:

On-Demand Network Verifier Demo