-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
-
False
-
-
-
OCMUI Core Sprint 276
Environment: Staging{}
Url: https://console.dev.redhat.com/openshift
Browser: MS edge , Chrome etc
OS: Mac 15.6
Priority* Major - Suspecting as the issue due to recent upgrade API handling(OCMUI-3145) in OCM UI
Reproduction steps:
- Open a ready OSD cluster allow version upgrade.
Note: I have chosen an OSD CCS wif GCP cluster that allows the version upgrade from 4.17.37 to 4.18.22. Wif config was outdated and block the cluster upgrade. - Go cluster's Settings tab.
- Click "Update" button.
- In "Update cluster" model, select the version.
- Click "Next" and proceed to next steps.
- Click "Confirm update" button
- See the behavior.
Current Result:
At step 7, the cluster update scheduling was failed with error due to wif-config verification failure. This is expected as wif config definition was outdated.
But the interesting fact that the "/upgrade_policies?dryRun=true" API call was initiated as soon as you launch the upgrade model but never waited for the response from the backend to decide if the configuration is correct or not /allowing user to proceed further.
If user wait for some more time (i.e. wait until the API call response)at step 4 i.e. in select version step then the error report and not allowing user to proceed further. This behavior seems wrong.
Expected Result:
The user should not be allowed to proceed from the first step of the Upgrade Cluster modal until the "/upgrade_policies?dryRun=true" API request has completed. Based on the response from this API, the system should determine whether the user is allowed to proceed to the next step.
Attached recording Screen Recording 2025-09-03 at 12.58.04 PM.mov
- links to