Drop init container annotations during conversion

[liggitt]

https://github.com/kubernetes/kubernetes/pull/51816/files#diff-0fa94eafdf1c7cd2171c836b53fd6323 removed special handling of init container annotations in API conversion in 1.8

However, older clients (like 1.7 kubectl) still performed that handling in some paths, which would make an object round-tripped through kubectl show up with additional annotations.

Those additions would get flagged as disallowed mutations in some objects.

This change strips init-container annotations during conversion so that old clients sending init container annotations (which are inert in 1.8+) don't trigger validation errors around immutable fields.

Fixes #54816

Restores the ability of older clients to delete and scale jobs with initContainers

[liggitt]

/kind bug
/sig apps
/priority important-soon

[liggitt]

cc @kubernetes/api-reviewers @janetkuo

[caesarxuchao]

#54816 happens in 1.7. An 1.7 kubectl creates the additional annotations, but the latest one shouldn't. Our version skew policy states that "client should be skewed no more than one minor version from the master", so I don't think we need this fix in the master. Can we directly target it to 1.7 and 1.8?

[caesarxuchao]

/sig api-machinery

[liggitt]

Can we directly target it to 1.7 and 1.8?

We can't make this change in 1.7 (since 1.7 still supports 1.5 kubelets, which require the annotation), only 1.8.

[liggitt]

I don't think we need this fix in the master

I'd like to treat init container annotations consistently... we still drop them in pod conversion. We can remove these when we remove that behavior.

[caesarxuchao]

I'd like to treat init container annotations consistently... we still drop them in pod conversion. We can remove these when we remove that behavior.

Perhaps I missed something, can we remove the special code in the pod conversion altogether? We are heading to 1.10, neither 1.8 kubelet or 1.9 kubectl will add the annotation.

[edit] If we decide that we need these special conversion functions, could you add a TODO saying when we can drop them?

[liggitt]

can we remove the special code in the pod conversion altogether? We are heading to 1.10, neither 1.8 kubelet or 1.9 kubectl will add the annotation.

We have to drop the annotations from the pod until we guarantee no kubelet honoring those annotations will make use of them. We don't support kubelets older than 2 versions skewed from the apiserver, but we don't prevent them, either, so I'd keep that drop in place for the immediate future.

[liggitt]

any other comments?

[k8s-github-robot]

[MILESTONENOTIFIER] Milestone Pull Request Current

@caesarxuchao @janetkuo @liggitt

Pull Request Labels

• sig/api-machinery sig/apps: Pull Request will be escalated to these SIGs if needed.
• priority/important-soon: Escalate to the pull request owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
• kind/bug: Fixes a bug discovered during the current release.

Help

• Additional instructions
• Commands for setting labels

[caesarxuchao]

/lgtm

[caesarxuchao]

We don't support kubelets older than 2 versions skewed from the apiserver, but we don't prevent them, either, so I'd keep that drop in place for the immediate future.

If you can get to it before it's merged, could you capture this in the comment of dropInitContainerAnnotations?

[liggitt]

If you can get to it before it's merged, could you capture this in the comment of dropInitContainerAnnotations?

updated

[caesarxuchao]

/lgtm

Thanks.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/apis/core/OWNERS [liggitt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.

[janetkuo]

@liggitt are we cherrypicking this into 1.8 and 1.9?

[liggitt]

Yes. Will open them shortly

[liggitt]

picks opened

[k8s-cherrypick-bot]

Commit found in the "release-1.9" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked.