Uploaded image for project: 'Red Hat Workload Availability'
  1. Red Hat Workload Availability
  2. RHWA-613

Revert FAR sharedSecretName default value

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Cause: Unfortunately the new sharedSecretName, which was introduced with the last release, had a default value.
      Consequence: It's not clear if that value was set by the user, or by defaulting. This makes validation and error handling difficult, when a Secret with that default value doesn't exist.
      Fix: The default value was removed. As a temporary workaround, the old default value is set in case the name is empty, but a Secret with that name exists. The other way around, when the name is set, but such a Secret doesn't exist, the field name will be deleted. Also deletion of the old default name will be prohibited when a Secret with that name exists, the Secret should be deleted first when it's not used anymore.
      Result: This change allows better validation and error handling, while the workaround ensures being as non disruptive as possible for users already using a Secret with the old default name.
      Show
      Cause: Unfortunately the new sharedSecretName, which was introduced with the last release, had a default value. Consequence: It's not clear if that value was set by the user, or by defaulting. This makes validation and error handling difficult, when a Secret with that default value doesn't exist. Fix: The default value was removed. As a temporary workaround, the old default value is set in case the name is empty, but a Secret with that name exists. The other way around, when the name is set, but such a Secret doesn't exist, the field name will be deleted. Also deletion of the old default name will be prohibited when a Secret with that name exists, the Secret should be deleted first when it's not used anymore. Result: This change allows better validation and error handling, while the workaround ensures being as non disruptive as possible for users already using a Secret with the old default name.
    • Bug Fix
    • Proposed

      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:

      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

              slintes Marc Sluiter
              slintes Marc Sluiter
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: