[IanBoden]

There was a version of the cli which added routingMode into the suiteCR so it's possible for clusters to have it set but for the operator to not look at it. When upgrading to 9.2 or updating from an early 9.2 version if it is set to path then the operator will try to change pathing modes which isn't supported.

Output of a test where injecting routingMode into the suite CR of a test system prior to trying an upgrade:

1. Set Target OpenShift Cluster
   Already connected to OCP Cluster:
   https://console-openshift-console.fvt811x-6f1620198115433da1cac8216c06779b-0000.us-south.containers.appdomain.cloud

Proceed with this cluster? [y/n] y

2. Instance Selection
   Select a MAS instance to upgrade from the list below:

• fvt811x v8.11.35-pre.maint811xdev

Enter MAS instance ID: fvt811x
Custom channel 9.2.x-dev
Fatal Error: Cannot upgrade to 9.2.x-dev: spec.settings.routingMode is set to "path" on the Suite CR.

This value was accidentally written to pre-9.2 Suite CRs and will cause the upgrade
pipeline to attempt an unintended routing mode switch.

To resolve this, remove the field from the Suite CR before retrying the upgrade:

oc patch suite fvt811x -n mas-fvt811x-core --type=json
-p '[{"op":"remove","path":"/spec/settings/routingMode"}]'

After applying the patch, re-run the upgrade.

We don't have to worry about upgrade from an early 9.2 patch to 9.3, as 9.3 feature channel wasn't added until after 9.2 supported path based routing.

[dixitgsathwara]

Should we not need to consider the upgrade plan for the unsupported 9.2 catalog to the 9.3 FC release? If someone upgrades from the unsupported 9.2 catalog to 9.3 FC where the Suite CR spec contains the routingMode path then it might create a problem.. or can we assume that prior to upgrading users must always update the latest 9.2 patch which contains PBR support? 🤔