Proposed title of this feature request

Kubelet feature gate compatibility update guards

What is the nature and description of the request?

When 4.y locks a given kubelet-config feature flag, 4.(y-1) clusters that set the flag to the opposite sense should be warned in a way that encourages them to pivot the flag before updating.

Why does the customer need this? (List the business requirements here)

OCPBUGS-6018 and MCO-457 are about the impact of a situation where the machine-config operator defaulted CSIMigrationOpenStack: false in 4.10 but the kubelet locked CSIMigrationOpenStack: true in 4.11, leading to a potential:

cannot set feature gate CSIMigrationOpenStack to false, feature is locked to true

on 4.10-to-4.11 updates. That's getting narrowly fixed, but the overall class of problems is larger, and customers could have their own KubeletConfigs setting flags which are about to be locked to the opposite sense in the next 4.y release.

Exposure is somewhat limited by the fact that maxUnavailable on the MachineConfigPool will limit the number of nodes that attempt to update into the incompatible config/kubelet pair. But still, it would be convenient to have some heads up to make config changes before there is any config/kubelet incompatibility.

List any affected packages or components.

Node and machine-config operator teams.