4 ms·

It's probably a niche use case, but there is some utility to having a guaranteed daily shutoff. For example, you might spin up an instance as an on-demand remot

It's probably a niche use case, but there is some utility to having a guaranteed daily shutoff. For example, you might spin up an instance as an on-demand remote dev environment, and the 24 hour cutoff ensures it doesn't accidentally get left on (over a weekend, for example). This would be easy to work around, but nonetheless could lead to unexpectedly high charges if you were relying on this behavior only to have it silently change.

roca 5y ago
In AWS we just `sudo shutdown +1440`. Then we can cancel the shutdown later if we need to.
- Tenoke 5y ago
  In AWS I set up a few lambdas to shut down my instances automatically because I've had some cases where everything crashes so thoroughly that the shutdown doesn't go off.
  - roca 5y ago
    That sounds painful!
- macintux 5y ago
  There's some bug we keep hitting that causes some EC2 instances to reboot on shutdown instead of halt and terminate. AWS engineers promised a fix months ago, no news yet.
cma 5y ago
Tha sounds like a horrific dev environment, if randomly shut down with 30 seconds notice.
- chromakode 5y ago
  One thing this helps with is keeping development environments up to date. When there's a large spread between instance lifetimes, it becomes more difficult to deploy updates and changes to developer infrastructure. This can grow into an org problem where shipping dev infra changes blocks on disrupting dev workflows. You can approach this by continuously deploying upgrades to the dev fleet, but it's simpler to simply set a lifetime bound (with an opt-out for special circumstances).
- jhugo 5y ago
  I can imagine it being useful if you needed to test something out for an hour or two and were worried you might forget to shut it down. Your charges are capped at 24h no matter how badly you screw up.
  - kubanczyk 5y ago
    If a test workload goes wrong in an interesting way, someone would very likely want to ssh there to poke around. If the poking extends to ~24 hours later, it is bound to get brutally interrupted. The worst part, there is no easy way to avoid it. (Well, one could shut it down and start again to reset the 24-hour timer, but that is cumbersome comparing to removing a `shutdown` line from crontab of a spot instance.)
- shock-value 5y ago
  "Horrific" is massive hyperbole, at least for my use case. (I actually use a GCP preemptible instance in this manner for a personal project, and spot instances will have the same shutoff risk.) I edit application code on my (relatively underpowered) laptop, and automatically mirror it to the instance where the running services picks up any changes, and recompiles and relaunches as needed. It's a fairly chunky app code-wise so moving the CPU usage off of my laptop is very helpful. When and if the instance shuts off early, I just relaunch it and reconnect. This amounts to one click of the mouse in the GCP UI, one locally run terminal command to connect, and one remote terminal command to (re)start my app. No work lost, and the cost savings are worth the minor inconvenience. Usually the instances last the full 24 hours anyway, and I usually shut it down when I'm done working, so interruptions are very rare. I can understand that in the context of a larger company with more resources, a dev would be put off by this. But it works very well for my uses.
  - cma 5y ago
    But what if you were in the middle of stepping through with the debugger?
Thristle 5y ago
It wasn't a 24H guarantee, it was UP TO 24h It did guard you from keeping things on by mistake but there are way more downsides to this kind of restrictions. Especially that you can simulate the daily shutoff like other comments here said

roca 5y ago

In AWS we just `sudo shutdown +1440`. Then we can cancel the shutdown later if we need to.

Tenoke 5y ago
In AWS I set up a few lambdas to shut down my instances automatically because I've had some cases where everything crashes so thoroughly that the shutdown doesn't go off.
- roca 5y ago
  That sounds painful!
macintux 5y ago
There's some bug we keep hitting that causes some EC2 instances to reboot on shutdown instead of halt and terminate. AWS engineers promised a fix months ago, no news yet.

cma 5y ago

Tha sounds like a horrific dev environment, if randomly shut down with 30 seconds notice.

chromakode 5y ago
One thing this helps with is keeping development environments up to date. When there's a large spread between instance lifetimes, it becomes more difficult to deploy updates and changes to developer infrastructure. This can grow into an org problem where shipping dev infra changes blocks on disrupting dev workflows. You can approach this by continuously deploying upgrades to the dev fleet, but it's simpler to simply set a lifetime bound (with an opt-out for special circumstances).
jhugo 5y ago
I can imagine it being useful if you needed to test something out for an hour or two and were worried you might forget to shut it down. Your charges are capped at 24h no matter how badly you screw up.
- kubanczyk 5y ago
  If a test workload goes wrong in an interesting way, someone would very likely want to ssh there to poke around. If the poking extends to ~24 hours later, it is bound to get brutally interrupted. The worst part, there is no easy way to avoid it. (Well, one could shut it down and start again to reset the 24-hour timer, but that is cumbersome comparing to removing a `shutdown` line from crontab of a spot instance.)
shock-value 5y ago
"Horrific" is massive hyperbole, at least for my use case. (I actually use a GCP preemptible instance in this manner for a personal project, and spot instances will have the same shutoff risk.) I edit application code on my (relatively underpowered) laptop, and automatically mirror it to the instance where the running services picks up any changes, and recompiles and relaunches as needed. It's a fairly chunky app code-wise so moving the CPU usage off of my laptop is very helpful. When and if the instance shuts off early, I just relaunch it and reconnect. This amounts to one click of the mouse in the GCP UI, one locally run terminal command to connect, and one remote terminal command to (re)start my app. No work lost, and the cost savings are worth the minor inconvenience. Usually the instances last the full 24 hours anyway, and I usually shut it down when I'm done working, so interruptions are very rare. I can understand that in the context of a larger company with more resources, a dev would be put off by this. But it works very well for my uses.
- cma 5y ago
  But what if you were in the middle of stepping through with the debugger?

Thristle 5y ago

It wasn't a 24H guarantee, it was UP TO 24h It did guard you from keeping things on by mistake but there are way more downsides to this kind of restrictions. Especially that you can simulate the daily shutoff like other comments here said