KEP-3453 minimize iptables-restore to Beta

[danwinship]

• One-line PR description: move KEP to beta GA beta

• Issue link: Minimizing iptables-restore input size #3453

• Other comments:

(For the moment this PR just exists to continue the conversation from #3454.)

/cc @wojtek-t

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[wojtek-t]

Sorry - I dropped it. Will get back to it this week.

/remove-lifecycle stale

[danwinship]

@wojtek-t We did a KEP review pass in the SIG Network meeting today, and @thockin was in favor of skipping Beta for this and just going straight to GA (perhaps "GA but with the feature gate still flippable, just in case").

Reiterating some discussion from the earlier PR: there was not any particular reason to think we were going to run into bugs with this code, and the examples in the KEP were just me brainstorming theoretical failure modes. Rather, the point of the KEP/feature gate was just that the possible badness was tiny_chance_of_bugs * huge_number_of_people_affected. But since testing in the perf e2e tests has not turned up bugs, we feel more confident about just inflicting it on everyone now.

[wojtek-t]

@danwinship - I still think that the metric that we were discussing would actually be useful, but I don't want trigger the pain, if I'm the only person who sees that metric as useful (and I looked into the code and agree that adding this metric wouldn't be super trivial task).

So for now, may I ask you to add two-three sentences about that into:
https://github.com/kubernetes/enhancements/pull/3454/files#diff-6efffdb08cfb3aefcb1047676bfdecec745cf9ad84879e07a34f151fc97dd96aR400
[Are there any missing metrics that would be useful to have to improve observability of this feature? section of the PRR]
so leave the clear trace that we spend time discussing that just decided not doing this?

[danwinship]

updated... I can't get "make verify" to run locally so let's see if it complains about me trying to skip beta...

/assign @thockin

[thockin]

The risk here is being able to disable it, if needed (your point from the call). While we CAN make a disableable GA, it's unusual and has little ROI here. So I think we should either:

a) Do a regular locked-on GA (YOLO!)
b) Do a regular beta

There's not much cost to beta - it will be on by default and disableable and it follows the normal flow.

Thoughts?

[wojtek-t]

I strongly believe we should make a beta.

As Tim pointed out, I don't think there is much of additional overhead.
Given we believe we're code-complete, Beta will effectively only be changing a feature gate.
And it gives us ability to disable that in case of problems (as opposed to GA that would be locked-on).

[danwinship]

@thockin I'm fine going through beta but don't the arguments in favor of it contradict your new "we should get rid of beta" proposal? 🙂

[wojtek-t]

I think my main request is to actually go through Beta. I also added couple other small comments, but those are more cosmetic.

[wojtek-t]

I strongly believe we should make a beta.

As Tim pointed out, I don't think there is much of additional overhead.
Given we believe we're code-complete, Beta will effectively only be changing a feature gate.
And it gives us ability to disable that in case of problems (as opposed to GA that would be locked-on).

[wojtek-t]

/approve PRR

Thanks!

[aojea]

/lgtm
/approve

beta sounds good, I have to update some scalability jobs anyway 😄

[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