KEP-4004: change from provisional to implementable

[danwinship]

• One-line PR description: KEP-4004 (deprecating node.status.kubeProxyVersion) got merged as "provisional" rather than "implementable". This just fixes that. (Meaning it needs PRR approval now.)

• Issue link: Deprecate status.nodeInfo.kubeProxyVersion field #4004
• KEP text link: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/4004-deprecate-kube-proxy-version

• Other comments:

/assign @wojtek-t

[danwinship]

cc @HirazawaUi

[HirazawaUi]

Thanks!

[wojtek-t]

Queued - will take a look later this week.

[wojtek-t]

Few comments:

0. High-level question: for an existing node with the field set, after enabling feature-gate will kubelet set the field to empty?
   Can you add an answer to this question explicitly to the KEP (in proposal section I guess)?

1. Testing strategy:

• the test I would additionally like to see (I guess it may be manual and it could probably be the one that would be effective the test in https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/4004-deprecate-kube-proxy-version#were-upgrade-and-rollback-tested-was-the-upgrade-downgrade-upgrade-path-tested ) is a test that ensures that after I disable the FG the field will be again propagated.

2. Feature gates:

• just double checking - won't kube-apiserver also depend on the FG? [I think it shouldn't and if someone sets the field it should accept it, but wanted to double check]

3. feature enablement/disablement tests

I only partially agree with the answer - I have two concerns:

• depending on the answer to my (0) question - we may want to actually verify if kubelet zero's the field
• independently of everything, I would like to see some test that ensures that after disablement of the FG (given the reason of that will most probably be "oops, something still depends on it"), ensure that this will actually be set

[I will have some additional comments for Beta, but I want to unblock Alpha first :) ]

[danwinship]

* just double checking - won't kube-apiserver also depend on the FG? [I think it shouldn't and if someone sets the field it should accept it, but wanted to double check]

We weren't planning to actually block access to the field. Just to have kubelet stop setting it. So no apiserver involvement.

[HirazawaUi]

1. for an existing node with the field set, after enabling feature-gate will kubelet set the field to empty

I think with feature-gate enabled, the kubelet sets the fields to empty.

[danwinship]

updated

[wojtek-t]

/approve PRR

/assign @thockin

[aojea]

/lgtm
/approve

[thockin]

Thanks!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea, danwinship, thockin, wojtek-t

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:

• keps/prod-readiness/OWNERS [wojtek-t]
• keps/sig-network/OWNERS [thockin]

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