@ammario FWIW, the reason behind templating the crontab is that we explicitly do not allow schedules that specify either day-of-month or month, as we expect schedules to be applicable weekly.
Should we also relax that restriction and allow users to build their workspace on the 29th of February?

Haha, well is there a technical reason for the restriction or is it that we consider it a very-unlikely use case?

I really can't think of any technical reason against -- just that someone could configure a workspace to stay running for one leap year.

Haha, I think we give them the full power of cron. It would be odd for them to start a workspace every leap year, but it's less cognitive overhead for them to use a familiar format.

I could see why one would want a monthly auto-stop. It's like a last resort measure to save costs.

Please include me on this breakout/decision -- I need to understand the UX and UI impact (@johnstcn ).

We can have a separate discussion for this from the one that will occur for #1433 and #634 , even if they're in the same meeting/back-to-back.

I think they're separate concerns.

Please add your planning poker estimate with ZenHub @johnstcn

For the moment we are going to maintain the current restrictions around crontab format as unlocking month and day-of-month options causes more complexity down the line.

For the moment we are going to maintain the current restrictions around crontab format as unlocking month and day-of-month options causes more complexity down the line.

Based on this comment, I'm going to close this as complete. I'll add [Decision] into the labels/title to reflect our decision.

We are going with

• autostart_schedule as a weekly schedule (HH:mm days-of-week)
• ttl --> time to live (duration)

Hold up one sec. There is also a timezone field in autostart_schedule, right?

And, is TTL bounded at all? Obviously if it's above 24h bugs ensue. Why use TTL instead of a fixed "Auto Stop" schedule? Does TTL apply if the user manually started the workspace?

(EDIT: formatting)

There is also a timezone field in autostart_schedule, right?

Correct. This defaults to UTC. Users can specify a timezone.

And, is TTL bounded at all?

It can be unset, and if set, we have not agreed on a set upper bound (apart from ~290 days which is the upper bound of the underlying data representation).

Obviously if it's above 24h bugs ensue.

Can you please enumerate some of the possible bugs you anticipate?
We will only use the TTL for automated workspace shutdowns, and Autostart Schedule only for automated workspace startups; both are idempotent operations.
If you're expecting DST-related timezone bugs, what do you imagine the expected vs actual behaviour to be in these cases?
Allowing workflows such as autostarting twice a day with a TTL of 2 hours could be purposefully and intended behaviour on the part of a user.

Why use TTL instead of a fixed "Auto Stop" schedule?

For the following reasons:

• (+) It makes the implementation of template-level thresholds simpler.
• (=) There has been no clear customer preference expressed that point to either a separate start and stop schedules, or a start schedule plus TTL.
• (+) The intent (at least what I percieve) behind "auto stop" is "do not leave workspaces running unnecessarily", and an autostop schedule does not map as cleanly to this concept.

Does TTL apply if the user manually started the workspace?

Autostop, if set, would apply if the user manually started the workspace, so TTL, if set, would also apply in this case.

Cool, I think the TTL is the right approach.

I see no "bugs" exactly, just behavior that isn't clear to me at first glance.

For example, if the TTL was set to 48 hours but the Auto Start starts the workspace start every 24 hours, would the workspace still turn off every 48 hours, or would each Auto Start reset the TTL timer?

For example, if the TTL was set to 48 hours but the Auto Start starts the workspace start every 24 hours, would the workspace still turn off every 48 hours, or would each Auto Start reset the TTL timer?

The only valid transition from a running workspace is to a stopped state, and vice-versa for a stopped state.
If the workspace is running, we check the TTL. If the workspace is stopped, we check the autostart schedule.
So, in the case you outline above, the workspace would remain running for 48 hours before stopping.

For example, if the TTL was set to 48 hours but the Auto Start starts the workspace start every 24 hours, would the workspace still turn off every 48 hours, or would each Auto Start reset the TTL timer?

The only valid transition from a running workspace is to a stopped state, and vice-versa for a stopped state. If the workspace is running, we check the TTL. If the workspace is stopped, we check the autostart schedule. So, in the case you outline above, the workspace would remain running for 48 hours before stopping.

If the TTL is an integer multiple of 24, then it could potentially stop the workspace right before it's started or stop the workspace right after it's started. To me this seems like behavior becomes more undefined as TTL approaches a 24 hour multiple.

We don't have to solve this issue now, I'm just making sure I understand the algorithm.

or stop the workspace right after it's started.

We measure TTL from the updated_at timestamp of the workspace's last build. If, for some reason, the provisioner failed to set that field correctly, we could potentially enter that situation. Unfortunately that's currently the only way I'm aware of to know how long a workspace has been up.

Ok... All makes sense to me.

Thanks @ammario for double-checking and making sure we have all our bases covered!

Thanks all, this was a fun data-centric problem to sort out

🌮 🎉 @ammario @johnstcn and support from @spikecurtis and @ketang

Of course I'm missing various folx that helped along the way and reviewed the RFC too!