Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix auto-pause interval value not immediately being taking affect #17945

Open
spowelljr opened this issue Jan 12, 2024 · 1 comment · May be fixed by #19900
Open

Fix auto-pause interval value not immediately being taking affect #17945

spowelljr opened this issue Jan 12, 2024 · 1 comment · May be fixed by #19900
Assignees
Labels
area/addons co/auto-pause lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@spowelljr
Copy link
Member

In #17936 I implemented making the auto-pause interval configurable, from the PR:

There's an issue with running minikube addons configure auto-pause, the value is successfully saved, but the value is not immediately updated in the auto-pause addon itself. The systemd unit file is updated, but then a systemctl daemon-reload & systemctl restart auto-pause.service both have to be run for the update to be reflected in the binary. Due to the already large size of this PR I'll leave it for a follow up.

As stated, when the user executes minikube addons configure auto-pause the change doesn't immediately take effect and systemctl daemon-reload & systemctl restart auto-pause.service need to be run. Calling sysinit.New(co.CP.Runner).Restart("auto-pause") would fix it, but the messy part is getting co which you would normally get via co := mustload.Running(profile). If we do implement it that way then minikube addons configure auto-pause with return an error when trying to execute the command when the cluster is stopped. But it gets confusing as the new interval value would actually be updated in the config, it's just the mustload.Running(profile) that failing.

We should only call mustload.Running(profile) after we confirm that the cluster is running, otherwise just update the value in the config.

@spowelljr spowelljr added area/addons priority/backlog Higher priority than priority/awaiting-more-evidence. co/auto-pause labels Jan 12, 2024
@k8s-triage-robot
Copy link

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

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

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 11, 2024
@spowelljr spowelljr added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Apr 11, 2024
@ComradeProgrammer ComradeProgrammer self-assigned this Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/addons co/auto-pause lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants