4 ms·

I don’t see this in the article, but is there any reason why they’d introduce a new VM type rather than just removing the 24hour limit of preemptible VMs?

dragonwriter 5y ago
Preemptible VMs are GA, Spot VMs are not; if there are changes that might be made to Spot before GA (such as other limits, etc.), this gives them the freedom to do that, without impacting those using Preemptible.
Thristle 5y ago
Branding probably. Being inline with Azure and AWS is helpful when onboarding new customers
shock-value 5y ago
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.
- 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
andoma 5y ago
I run a small CI system which starts relatively beefy preemptible instances for jobs. Normally those instances are terminated by the job scheduler as soon as there's nothing more to do. But it's a great peace of mind knowing they can't run for more than 24h if my job scheduler screws something up for whatever reason. I see it as a feature rather an a limitation for my use case.
- kevincox 5y ago
  Yes, but they could just provide a flag `maxLifetime` which defaults to `24h` but can be set to 0. (It can even only accept those two values) Instead they created a whole new API for basically the same feature.
  - willcipriano 5y ago
    Creating a new api has greater "impact".
  - andoma 5y ago
    This would be superior of course. Ideally being able to limit maximum runtime down to one hours.
londons_explore 5y ago
It smells like some person/team trying to get a promotion for launching a big new feature, rather than their perf packet saying "added option to not terminate after 24h". Functionally, I see no difference.

dragonwriter 5y ago

Preemptible VMs are GA, Spot VMs are not; if there are changes that might be made to Spot before GA (such as other limits, etc.), this gives them the freedom to do that, without impacting those using Preemptible.

Thristle 5y ago

Branding probably. Being inline with Azure and AWS is helpful when onboarding new customers

shock-value 5y ago

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.
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

andoma 5y ago

I run a small CI system which starts relatively beefy preemptible instances for jobs. Normally those instances are terminated by the job scheduler as soon as there's nothing more to do. But it's a great peace of mind knowing they can't run for more than 24h if my job scheduler screws something up for whatever reason. I see it as a feature rather an a limitation for my use case.

kevincox 5y ago
Yes, but they could just provide a flag `maxLifetime` which defaults to `24h` but can be set to 0. (It can even only accept those two values) Instead they created a whole new API for basically the same feature.
- willcipriano 5y ago
  Creating a new api has greater "impact".
- andoma 5y ago
  This would be superior of course. Ideally being able to limit maximum runtime down to one hours.

londons_explore 5y ago

It smells like some person/team trying to get a promotion for launching a big new feature, rather than their perf packet saying "added option to not terminate after 24h". Functionally, I see no difference.