[KEP 3458]: 1.29 milestone bump - stable

[alexanderConstantinescu]

• One-line PR description: 1.29 milestone bump for KEP - 3458. Bumping to stable

• Issue link: Remove transient node predicates from KCCM's service controller #3458

• Other comments: none

/sig network
/assign @thockin
/assign @wojtek-t

[wojtek-t]

Few comment about the KEP itself:

1. In mitigations section:

For point 3. we could implement the following change in the service controller [...]

has that happened? If not, why we believe we don't need it? can you update the KEP?

Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested

has this happened? Can you please update the KEP with the test description and findings?

A new metric load_balancer_sync_count will be added

Has this happened?

A new metric nodesync_error_rate will be added

Has this happened?

[alexanderConstantinescu]

has that happened? If not, why we believe we don't need it? can you update the KEP?

Yes. The service controller still employs the predicate which excludes nodes with the taint ToBeDeletedByClusterAutoscaler, see: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cloud-provider/controllers/service/controller.go#L1009-L1014C26

has this happened? Can you please update the KEP with the test description and findings?

No

Has this happened?

Yes, see: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cloud-provider/controllers/service/metrics.go#L44-L49

Has this happened?

Yes, see: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cloud-provider/controllers/service/metrics.go#L50-L55

[wojtek-t]

For the "yes" thing - please update the KEP to reflect that (with links).

For the no thing [the test thing], can we try running something? @thockin - FYI

[alexanderConstantinescu]

For the "yes" thing - please update the KEP to reflect that (with links).

Done.

For the no thing [the test thing], can we try running something?

I am not sitting on infrastructure which allows me to create cluster from HEAD. That being said: I quite sure the upgrade path works because this has been enabled by default since 1.27 and my company has successfully upgraded clusters from 1.26 -> 1.27, with services existing on the cluster that are impacted by this change.

[thockin]

I can help get access to infra to do this manual testing, if that's what we need. That said, I'm a little skeptical that we will find anyhing by just doing it, without a) knowing what we are looking for; and b) tickling the edge cases specifically.

[wojtek-t]

OK - I buy that.

But then let's update the Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested? PRR question to something like

The owners of the KEP missed running the manual test when promoting the feature to Beta. Since then it was implicitly tested by many users that upgraded their clusters to 1.27+ versions without any bug reports, so running additional tests now wouldn't provide additional value.

[alexanderConstantinescu]

I've updated the answer to that question.

[thockin]

/lgtm
/approve

/hold

to discuss manual testing

[thockin]

I can help get access to infra to do this manual testing, if that's what we need. That said, I'm a little skeptical that we will find anyhing by just doing it, without a) knowing what we are looking for; and b) tickling the edge cases specifically.

[thockin]

Thanks!

/lgtm
/approve

[wojtek-t]

/lgtm
/approve PRR

Thanks!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexanderConstantinescu, 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