When we introduced secret usage in FAR, we added a new field to the FAR spec for the name of the shared secret. In order to be backwards compatible, the field needs to be optional. Unfortunately though we added a default value (via API) to it.

This has multiple issues:

• updating the default would be an backwards incompatible change (think of reinstalling clusters with new operator versions, when the empty field suddenly gets a different value than before)
• we don't know if the user actually wants to use a Secret with the given default name, because you can't leave it empty, which makes reasonable validation impossible
• if a default behavior for empty fields really makes sense, implement it in code instead. Explain in API description and add that the default behavior can change

more context:

• https://redhat-internal.slack.com/archives/C03M5GKJNBA/p1768222217519389
• https://github.com/medik8s/fence-agents-remediation/pull/177#discussion_r2447515829

action:

• Remove default from API definition
  • Explain this change in the API description and a release note
• For keeping backwards compatibility:
  • Check in code if secret with deprecated default name exists:
    • If yes: use it, no matter if API field is set
      • Optional: set API field in order to get rid of this workaround in a later version? Usually modifying the spec is bad practice, but in this case it is reasonable IMHO and would be good for future versions
    • If no:
      • When API field is nil: no action, no shared secret is used
      • When API field is set with old default value:
        • This is tricky....
          • report validation failure?
            • This would be a change to old behaviour...
          • Ignore?
            • That would be bad validation...
          • Remove default value from API field?
            • Usually modifying the spec is bad practice, but in this case it is reasonable IMHO and would be good for future versions (removing workaround). In case we remove the field value, but a secret is added later, we would run into the "If yes" case above, so no issue
  • For any other value given in the API: if the secret doesn't exist, report validation failure