Description of problem:

Apparently our existing wording is not sufficient to convince external customers that forcing a rollback is a risky move. Tighten the wording to try to be even more clear about the potential downsides. The guards force blasts through are designed to keep you safe!

Version-Release number of selected component

Definitely 4.21. I haven't gone hunting through older releases to see how far back the API Godocs patch applies cleanly.

How reproducible

Every time.

Steps to Reproduce

Read the ClusterVersion API docs, e.g. the 4.19 spec and desiredUpdates docs.

Actual results

Setting the desired update value back to the previous version will cause a rollback to be attempted. Not all rollbacks will succeed.

and:

force allows an administrator to update to an image that has failed verification or upgradeable checks. This option should only be used when the authenticity of the provided image has been verified out of band because the provided image will run with full administrative access to the cluster. Do not use this flag with images that comes from unknown or potentially malicious sources.

Expected results

Setting the desired update value back to the previous version will cause a rollback to be attempted if the previous version is within the current minor version. Not all rollbacks will succeed, and some may unrecoverably break the cluster.

and:

force allows an administrator to update to an image that has failed verification or upgradeable checks that are designed to keep your cluster safe. Only use this if:

• you are testing unsigned release images in short-lived test clusters or
• you are working around a known bug in the cluster-version operator and you have verified the authenticity of the provided image yourself.

The provided image will run with full administrative access to the cluster. Do not use this flag with images that comes from unknown or potentially malicious sources.