We're answered the following questions to evaluate whether or not OCPBUGS-20104 warrants changing update recommendations:

Which 4.y.z to 4.y'.z' updates increase vulnerability?

• reasoning: This allows us to populate from and to in conditional update recommendations for "the $SOURCE_RELEASE to $TARGET_RELEASE update is exposed.
• answer: Customers upgrading from 4.14.0-rc.3 (and later RC until OCPBUGS-20184 lands a fix in 4.14) might have trouble updating to later 4.14 (pre)releases with the fix for OCPBUGS-20184. Use oc adm upgrade to show your current cluster version.

Which types of clusters?

• reasoning: This allows us to populate matchingRules in conditional update recommendations for "clusters like $THIS".
• answer: Standalone (non-HyperShift) OVN clusters (although the hypershift control plane cluster would be affected), or any clusters with Multus enabled (it is enabled by default, so likely almost all clusters).

What is the impact? Is it serious enough to warrant removing update recommendations?

• reasoning: This allows us to populate name and message in conditional update recommendations for "...because if you update, $THESE_CONDITIONS may cause $THESE_UNFORTUNATE_SYMPTOMS".
• answer: OVN and Multus webhook handlers could wedge updating from rc.3 (or rc.4, etc.) to a (pre)release where OCPBUGS-20184 has been fixed, as an outgoing root listener fights for the port with an incoming non-root listener.

How involved is remediation?

• reasoning: This allows administrators who are already vulnerable, or who chose to waive conditional-update risks, to recover their cluster. And even moderately serious impacts might be acceptable if they are easy to mitigate.
• answer: oc delete --force=true -n openshift-network-node-identity --all pods. This will remove the root pods and they will be recreated using the new definition.

Is this a regression?

• reasoning: Updating between two vulnerable releases may not increase exposure (unless rebooting during the update increases vulnerability, etc.). We only qualify update recommendations if the update increases exposure.
• answer: Yes, 4.14.0-rc.3 landed ovn-org/ovn-kubernetes#3830 via openshift/ovn-kubernetes#1885, which added a root webhook whose user OCPBUGS-20184 will adjust This Webhook is also enabled when Multus is present even if OVN Kubernetes is not used.