Description of problem

IR-407 and other similar 4.15 work around moving to GCP custom credentials means 4.15 mint mode GCP clusters will need additional roles associated with their root (minting) credential. Clusters which lack those roles may stick in 4.14-to-4.15 updates with failures like:

$ oc -n openshift-cloud-credential-operator get -o json credentialsrequests | jq -r '.items[] | select(tostring | contains("InfrastructureMismatch") | not) | .metadata.name as $n | .status.conditions // [{type: "NoCon
ditions"}] | .[] | .type + "=" + .status + " " + $n + " " + .reason + ": " + .message' | sort
...
CredentialsProvisionFailure=True openshift-ingress-gcp CredentialsProvisionFailure: failed to grant creds: error syncing creds in mint-mode: error creating custom role: rpc error: code = PermissionDenied desc = You don't have permission to create a role in projects/...
...

The 4.14 cloud-cred opeator should grow a guard to inform any exposed customers before they launch the update into 4.15, so they can calmly plan their changes ahead of tim, and not be surprised mid-update.

Version-Release number of selected component

4.14-to-4.15 updates are exposed. The 4.14.z releases need a patch to encode this new guard.

How reproducible

Every time.

Steps to Reproduce

1. Install a 4.14 GCP cluster.
2. Set the root secret to one with 4.14's minimal permissions.
3. Launch an update to 4.15.

Actual results

The update sticks on a Degraded=True CCO ClusterOperator, which is in turn because the minting cred lacks permission to provision the incoming 4.15 ingress credential.

Expected results

GCP mint mode admins on 4.14 are informed of the need to adjust their minting credential, and the CVO does not allow unforced updates to begin until there is som sign that has happened.

Additional info

• https://github.com/openshift/cloud-credential-operator/blob/42a0af3fa56b3c530dba1062fb316ac2021541dc/pkg/operator/utils/utils.go#L366
• FIXME: float some implementation options