3 ms·

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

by cma 5y ago

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?

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

by cma 5y ago

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

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?