This story may not be necessary if we update the rootCA configmap(this effectively updated the *-user-data-managed secrets) and the *-user-data secret. Let's keep this as a low priority task for the moment until the MVP of this epic is accomplished(CA and the cert can be rotated)

Update (11/18/24)

sregidor@redhat.com raised a great point on the PR; some stubs may still be 2.2.0 and the cert controller does not handle upgrading them to 3.2. Removing this injection from the MSBIC may cause newer bootimages that only support spec 3 ignition to attempt to use a 2.2 stub and fail. This needs some further evaluation of the following scenarios:

• if the cert controller can determine that the stubs are 3+, we're in the ideal world
• if the cert controller can determine that the stubs are 2.2 and not upgradeable, should we
  1. make using the managed secret mandatory for all machinesets?
  2. indicate to the user that they should update their stub to 3.x manually as a one time process, so boot images and rotation can be supported? (perhaps a mechanism similar to the one proposed in MCO-1295)
  3. force a "clean" 3.x stub, and let the user add what they need after the fact?