auto-pause: Using time.Ticker instead of time.Timer to fire idle time-out event.

[hetong07]

Fix #10596

Using time.Ticker to replace time.Timer to solve the timer memory leak issue. Refer to this blog for more details.

[k8s-ci-robot]

Hi @hetong07. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[minikube-bot]

Can one of the admins verify this patch?

[hetong07]

@medyagh Do we need to wrap the idleTimer and its parameter check into a helper function? Feel like we can let PR for #10595 to make this decision?

Another question is I tried the auto-pause feature, but I notice after 1 minutes only the kubelet stopped, the apiserver is still running, shown below.

$ ./out/minikube status                                                                                                   
minikube
type: Control Plane
host: Running
kubelet: Stopped
apiserver: Running
kubeconfig: Configured
timeToStop: Nonexistent

This behavior is different than the description in your original PR #10427 , is this behavior intended?

[medyagh]

@medyagh Do we need to wrap the idleTimer and its parameter check into a helper function? Feel like we can let PR for #10595 to make this decision?

Another question is I tried the auto-pause feature, but I notice after 1 minutes only the kubelet stopped, the apiserver is still running, shown below.

$ ./out/minikube status                                                                                                   
minikube
type: Control Plane
host: Running
kubelet: Stopped
apiserver: Running
kubeconfig: Configured
timeToStop: Nonexistent

This behavior is different than the description in your original PR #10427 , is this behavior intended?

@hetong07 on my machine it works (mac docker driver)

``
$ minikube addons enable auto-pause
▪ Using image gcr.io/haproxy:2.3.5
▪ auto-pause addon is an alpha feature and still in early development. Please file issues to help us make it better.
▪ co/auto-pause
🌟 The 'auto-pause' addon is enabled

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c94347742976 gcr.io/k8s-minikube/kicbase:v0.0.18 "/usr/local/bin/entr…" 4 minutes ago Up 4 minutes 127.0.0.1:55034->22/tcp, 127.0.0.1:55033->2376/tcp, 127.0.0.1:55032->5000/tcp, 127.0.0.1:55031->8443/tcp, 127.0.0.1:55030->32443/tcp minikube
10:32:38 medya/workspace/minikube
pod_preset •3 ⌅1
$ code ~/.kube/config
10:33:27 medya/workspace/minikube
pod_preset •3 ⌅1
$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Stopped
apiserver: Paused
kubeconfig: Configured
timeToStop: Nonexistent

[ilya-zuyev]

Please reset the ticker after each 'unpause' event

[hetong07]

@medyagh strange, I repeadly see the API service running, maybe configuration issue?

$ ./out/minikube status                                                                                                    
minikube
type: Control Plane
host: Running
kubelet: Stopped
apiserver: Running
kubeconfig: Configured
timeToStop: Nonexistent

[azhao155]

@medyagh @ilya-zuyev why do we need to reset ticker? according to the blog. it should be reset by itself:

"It is good to use the ticker timer directly, because the ticker is executed once every certain period of time. Generally, it can be executed multiple times, which is equivalent to calling timer timer time.Reset ."

[hetong07]

@medyagh @ilya-zuyev why do we need to reset ticker? according to the blog. it should be reset by itself:

"It is good to use the ticker timer directly, because the ticker is executed once every certain period of time. Generally, it can be executed multiple times, which is equivalent to calling timer timer time.Reset ."

I think we have to reset it due to the racing conditions, as @ilya-zuyev stated in previous comments.

[k8s-ci-robot]

@hetong07: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ilya-zuyev]

lgtm, could you rebase this PR and we can merge it

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hetong07, ilya-zuyev

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:

• OWNERS [ilya-zuyev]

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

[ilya-zuyev]

/ok-to-test

[k8s-ci-robot]

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

Test name	Commit	Details	Rerun command
pull-minikube-build	00526e1	link	/test pull-minikube-build

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[andriyDev]

@hetong07 Unsure if you're still around, we'd love to merge this PR. We just need it to be rebased! If we don't hear from you in a few days, I may just take ownership of this PR (creating a new PR with the same content).

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[k8s-triage-robot]

The lifecycle/frozen label can not be applied to PRs.

This bot removes lifecycle/frozen from PRs because:

• Commenting /lifecycle frozen on a PR has not worked since March 2021
• PRs that remain open for >150 days are unlikely to be easily rebased

You can:

• Rebase this PR and attempt to get it merged
• Close this PR with /close

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

/remove-lifecycle frozen

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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:

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active 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:

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

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

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.