Clear values for disabled alpha fields

[liggitt]

Fixes #51831

Before persisting new or updated resources, alpha fields that are disabled by feature gate must be removed from the incoming objects.

This adds a helper for clearing these values for pod specs and calls it from the strategies of all in-tree resources containing pod specs.

Addresses kubernetes/community#869

[liggitt]

cc @kubernetes/sig-api-machinery-pr-reviews @kubernetes/api-reviewers

[ncdc]

Ouch... For once, I think back to my Java days with annotations and AOP. It sure would be nice to annotate a field as alpha and have a cross-cutting concern apply logic consistently everywhere. /sigh

[mml]

cc @jpbetz

[lavalamp]

This looks to be a hand-written version of something that would be covered by the field gate proposal: https://docs.google.com/document/d/1wuoSqHkeT51mQQ7dIFhUKrdi3-1wbKrNWeIL4cKb9zU/edit

I've glanced at this and I'm worried it will evolve into something unmaintainable. Actually I think this is already unmaintainable. How important is it for these to be cleared?

[liggitt]

This looks to be a hand-written version of something that would be covered by the field gate proposal

Yes. In the absence of field gate support, this is what we get for 1.8. I'm happy to remove this as soon as an automated/generated solution is available.

Actually I think this is already unmaintainable

It's certainly ugly and not my first preference, but I don't see field gates landing in the next week.

How important is it for these to be cleared?

If we don't clear these, requests to the server that include these fields will be rejected, which is not what we want to happen (a server that disables the alpha field should drop the field from the incoming request, per kubernetes/community#869 (comment)). That would mean that if these fields graduate to beta and start getting used in a future release, a client submitting a manifest with those fields would get these responses:

• 1.7 server would drop the fields
• 1.8 server would reject the request
• 1.9 server would accept the request

1.7 and 1.8 should behave identically

[bgrant0607]

If we don't clear the fields, then we don't solve one of the main problems with annotations that we wanted to solve by moving away from annotations. (#30819)

[liggitt]

/retest

[lavalamp]

I agree with the intent but I still feel like this is adding technical debt rather than removing it. Also, the chance that everyone making such a field remembers to clear it like this seems quite low. Unfortunately I don't have a better suggestion.

[liggitt]

I agree with the intent but I still feel like this is adding technical debt rather than removing it. Also, the chance that everyone making such a field remembers to clear it like this seems quite low. Unfortunately I don't have a better suggestion.

I don't disagree, but I also couldn't come up with anything better for the 1.8 timeframe. Inaction leaves 1.8 in a state we don't want.

[smarterclayton]

Do we need to drop the resource field as well?

[liggitt]

no, that's a key/value in an existing field... these are new fields

[liggitt]

need to make a decision on this or provide an alternative

[smarterclayton]

/lgtm

[smarterclayton]

/approve no-issue

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, smarterclayton

Associated issue: 51831

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• pkg/api/OWNERS [liggitt,smarterclayton]
• pkg/registry/OWNERS [smarterclayton]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 51682, 51546, 51369, 50924, 51827)