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
Given that prebuilt instances will be consuming (potentially very expensive) cloud resources, operators will need a mechanism to scale down (or to 0) when not needed.
We can expose an autoscaling field under coder_workspace_preset:
data"coder_workspace_preset""us-nix" {
...prebuilds={
instances =0# default to 0 instances
autoscaling = {
timezone ="UTC"# only a single timezone may be used for simplicity# scale to 3 instances during the work week
schedule {
cron ="* 8-18 * * 1-5"# from 8AM-6PM, Mon-Fri, UTC
instances =3# scale to 3 instances
}
# scale to 1 instance on Saturdays for urgent support queries
schedule {
cron ="* 8-14 * * 6"# from 8AM-2PM, Sat, UTC
instances =1# scale to 1 instance
}
}
}
}
The solution above is designed to mirror the autostart scheduling.
The crontab format will already be familiar to operators, and will be intuitive to understand. The design above allows operators to specify a default number of instances, and then to scale that number dynamically based on one or more schedules. This can either be used to start from 0 and scale up (as the example above demonstrates), or the inverse; whichever the operator prefers.
This design would also allow for validation at template import time, where we will detect scheduling conflicts (i.e. if multiple schedules overlap and produce different values).
This will require a simple ticker to evaluate when the current time matches the crontab expression of a schedule, and to trigger the appropriate reconciliation in the reconciliation loop.
The text was updated successfully, but these errors were encountered:
Relates to #311 and #304:
Given that prebuilt instances will be consuming (potentially very expensive) cloud resources, operators will need a mechanism to scale down (or to 0) when not needed.
We can expose an
autoscaling
field undercoder_workspace_preset
:The solution above is designed to mirror the autostart scheduling.
The crontab format will already be familiar to operators, and will be intuitive to understand. The design above allows operators to specify a default number of instances, and then to scale that number dynamically based on one or more schedules. This can either be used to start from 0 and scale up (as the example above demonstrates), or the inverse; whichever the operator prefers.
This design would also allow for validation at template import time, where we will detect scheduling conflicts (i.e. if multiple schedules overlap and produce different values).
This will require a simple ticker to evaluate when the current time matches the crontab expression of a schedule, and to trigger the appropriate reconciliation in the reconciliation loop.
The text was updated successfully, but these errors were encountered: