Feature Request: Auto scaling, better, more cost effective timing options
The current situation is, that an instance is shutdown, after it reaches its idle timeout.
But this is not really the best way to do it, for example on DigitalOcean this causes unnecessary wasted costs and resources.
To citate the digitalocean support:
The creation time of the Droplet is when the billing starts, so the spin up time is included in the billable time. The minimum billable time increment is 1 hour, if you have 2 Droplets spun up and destroyed within 30 minutes we would still charge 2 hours total. The unused half hour would be "lost". We calculate charges and create invoices at the end of the month. You will not be charged automatically right when creating a Droplet.
And another answer from them also making this more clear:
B/c this opens another question: Give the following scenario
I have started a new droplet run it for 10 minutes and shut it down. 2 hours later I start another new droplet run it for 10 minutes again. Do I get charged for 1 hour now, or are you going to charge me for 2 hours? I understand that you will bill me 2 hours when I do run two droplets in parallel, but this is more about when I do recreate droplet.
Because each Droplet is billed by the hour, using just one ten minutes of a Droplet is (to our system) one hour. So opening another Droplet for 10 more minutes would just be another hour to our billing system, meaning you'd accrue 2 hours of Droplet charges. Additional services (automatic backups, etc.) may lead to further charges.
So what would be useful is to have the option to define billable timespans. For example:
Setting a billable timespan of 1 hour and an idle time of 3600 means: Do idle for 1 hour, but do not stop if > 1 hour.
This would have the effect: A droplet would not stop when running out at a time of usage of 3700 seconds even if the timeout defines this like that. It would instead run for the timespan of 7000 seconds (3500 seconds * 2). I drop 100 seconds here for the spin up time that might not be recognized by gitlab multi ci runner and thus would generate costs of an additional new hour.