# Scheduled shutdown and pause

* First proposed: 2020-04-20
* Authors: Thomas Stromberg (@tstromberg)
  
## Reviewer Priorities

Please review this proposal with the following priorities:

* Does this fit with minikube's [principles](https://minikube.sigs.k8s.io/docs/concepts/principles/)?
* Are there other approaches to consider?
* Could the implementation be made simpler?
* Are there usability, reliability, or technical debt concerns?

Please leave the above text in your proposal as instructions to the reader.

## Summary

Add the ability to schedule a future shutdown or pause event.

This is useful for two sets of users:

* command-lines which interact with a minikube on per-invocation basis. These command-line tools may not be aware of when the final invocation is, but would like low-latency between-commands
* IDE's which start minikube on an as-needed basis. Not all IDE's have the ability to trigger exit hooks when closed.

## Goals

* The ability to schedule a pause or shutdown event
* The ability to defer the scheduled pause or shutdown event
* "minikube start" transparently clears pending scheduled events

## Non-Goals

* Automatic idle detection: This is a more advanced, but complimentary idea, that would keep users from having to invoke a keep-alive command. It is possible to create using the same mechanisms, but is beyond the scope of this proposal.

* Automatic re-activation: This is significantly more advanced, particularly for the scheduled shutdown case. It would be possible to create this, but it to is out of scope for this proposal.

## Design Details

### Proposed interface:

* `minikube pause --after 5m`
* `minikube stop --after 5m`

* Each scheduled pause would overwrite the previous scheduled event.
* Each scheduled stop would overwrite the previous scheduled event.
* Each call to `minikube start` would clear scheduled events

As a `keep-alive` implementation, tools will repeat the command to reset the clock, and move the event 5 minutes into the future.

### Implementation idea #1: host-based

* If `--schedule` is used, the minikube command will daemonize, storing a pid in a well-known location, such as `$HOME/.minikube/profiles/<name>/scheduled_pause.pid`.
* If the pid already exists, the previous process will be killed, cancelling the scheduled event.

Advantages:

* Able to re-use all of the existing `pause` and `stop` implementation within minikube.
* Built-in handling for multiple architectures
* Does not consume memory reserved for the VM

Disadvantages:

* Runs a background task on the host
* Daemonization may require different handling on Windows

### Implementation idea #2: guest-based

minikube would connect to the control-plane via SSH, and run the equivalent of:

```shell
killall minikube-schedule
sleep 300

for node in $other-nodes; do
  ssh $node halt
done
halt
```

Advantages:

* Consistent execution environment

Disadvantages:

* Requires creation of a helper binary that runs within the VM
* Untested: some drivers may not fully release resources if shutdown from inside the VM