feature: Evolve an API by Changing Field Validation

[stevekuznetsov]

Feature Description

As a service provider exposing an API through an export,
I would like to change the validation rules for an existing field in my API
In order to better support the features I provide

Proposed Solution

We need to support:

• marking an optional field required
• marking a required field optional
• adding validation to data that was previously weakly-specified
• removing validation from data that was strongly validated

We expect to support all of the following patterns:

• ratcheting validation original design:
  • new rules take effect in version n
  • CREATE on n-1 applies validation rules
  • UPDATE on n-1 applies validation rules if they already pass - can't make a valid object invalid
  • on storage migration (when no old version exists in etcd) we can have strict validation in all cases
  • case study: OAuthAccessToken prefixed with sha256~ : https://github.com/openshift/enhancements/blob/master/enhancements/authentication/oauth-resource-storage.md#proposal
• feature starving
  • features from newer APIs are not available functionally to clients creating previous versions
  • case study: CustomResourceDefinition use of structural schemas: https://kubernetes.io/blog/2019/06/20/crd-structural-schema/#conclusion
• prior release controller-based normalization
  • API author indicates what normalization is to occur and gets some (?) guarantee about eventual consistency of stored data
  • case study: [@sttts TODO]

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

Extracted from this design doc.