@mfojtik: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

/triage accepted

this is required to merge first:
#94723

@mfojtik: PR needs rebase.

Hello 👋 ! Bug triage here, This PR has not been updated for a long time, so I'd like to check what's the status. The code freeze is starting 12.11.2020 (about 2 weeks from now) and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time.

As the PR is tagged for 1.20, is it still planned for this release?

I think we should consider leaving the insecure-port flag registered, marked deprecated (so it doesn't appear in help), inert (not wired to anything) and only accepting a value of '0' for several releases.

Having the insecure-port wired to zero seems more vague than just removing it. Removing it sends a clear message its gone and you cannot rely on it anymore. If you have something like health checks or component status calls being sent to the insecure port they will stop working. Setting the value to 0 implies the same thing, but I think its better to be clear in this instance.

Having the insecure-port wired to zero seems more vague than just removing it. Removing it sends a clear message its gone and you cannot rely on it anymore. If you have something like health checks or component status calls being sent to the insecure port they will stop working. Setting the value to 0 implies the same thing, but I think its better to be clear in this instance.

The rationale was stated in #95522 (review), and focused on preventing accidents in deployers stopping setting the flag to 0 too early:

Well-behaved deployers are passing --insecure-port=0 everywhere right now in order to disable insecure serving. Removing the flag completely will force them to instantly update configs/manifests/deployment processes to omit that flag. If those updates accidentally omit the flag from a manifest for a previous version, that will re-enable insecure serving on that version.

I would much rather have an "only accept 0" flag and leave it silently registered for a few releases than risk an accident.

@cheftako @liggitt @neolit123 @mfojtik are there other bits/blockers to discuss to have this merged? @mfojtik is busy, I was asked to politely take over. We have one week left before the code freeze.

#96216 is doing the same for kube-controller-manager. Might be better to do it per component than to open one huge PR so we don't have to rebase so often and divide the work between individuals.

@ahg-g @alculquicondor for kube-scheduler. Are you aware of this effort?

The insecure API server port was already removed in #95856 which was the priority for 1.20

I tend to agree that going component by component and neutering the insecure port is likely to be simpler

+1 on a PR per component

kube-scheduler bits: #96345

/milestone clear

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

@fejta-bot: Closed this PR.