You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current situation for auto shutdown appears to be:
When you create a Coder Workspace, it will be scheduled to automatically shut down after the TTL set in the template has passed, or what the user has configured in the Workspace schedule. If Coder detects any activity (through SSH/Port forwarded connections?), and the Workspace would be shut down in under one hour, it will extend the shut down time to one hour.
Sometimes the "Stops at" information is not shown on a Workspace, and I'm not sure why, but when it is, you can only use it to reduce the time at which the Workspace is stopped, or increase it back up to the max TTL.
What I would really like to see is:
Ability to increase the lifetime above the max TTL. This could be achieved by introducing a default TTL that is used when the Workspace is created, and users can increase it up to the max TTL.
Ability to set a shutdown by date & time instead of by "+ hours".
Allow setting a fixed time in the schedule at which the workspace will be shutdown (unless activity is detected or the lifetime was manually extended), similar to how we can currently specify startup times.
This would be great for AI research where the allocated resources are very expensive. Having a low "default TTL" ensures that we shut down the workspace sooner than later. Currently I wouldn't be able to set the max TTL below 48 hours to allow me to allow the workspace can actually live for this long (to complete scheduled trainings that might take >24h to complete), but this also means that unless I remember to shut down the workspace when I don't need it to run over night, it will just keep running.
Related side question: Is it possible to stop the Workspace from inside the workspace without requiring the user to run coder login from inside the Workspace first? This could enable to set up a Cron-job that would periodically check resource usage and stop the workspace based on that information.
The text was updated successfully, but these errors were encountered:
Doing stop from inside the workspace for example when training ends seems like great idea. This will save a lot of money and resources.
May be a python package that can trigger workspace stop when called at the end of a script.
I think if losing contact with an agent would trigger a Terraform workspace refresh (or doing it on some sort of routine basis), it would suit these situations well where the compute resource changes state outside of an action in Coder. I have a use-case for this as well where I want aggressive background processes controlling high-cost instances.
This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.
The current situation for auto shutdown appears to be:
Sometimes the "Stops at" information is not shown on a Workspace, and I'm not sure why, but when it is, you can only use it to reduce the time at which the Workspace is stopped, or increase it back up to the max TTL.
What I would really like to see is:
This would be great for AI research where the allocated resources are very expensive. Having a low "default TTL" ensures that we shut down the workspace sooner than later. Currently I wouldn't be able to set the max TTL below 48 hours to allow me to allow the workspace can actually live for this long (to complete scheduled trainings that might take >24h to complete), but this also means that unless I remember to shut down the workspace when I don't need it to run over night, it will just keep running.
Related side question: Is it possible to stop the Workspace from inside the workspace without requiring the user to run
coder login
from inside the Workspace first? This could enable to set up a Cron-job that would periodically check resource usage and stop the workspace based on that information.The text was updated successfully, but these errors were encountered: