Please add your planning poker estimate with ZenHub @johnstcn

Left desc blank on purpose - want to double-check we still want pre-emptive extension for CE. Even if we don't, we still need reactive extension. The difference between the two can be further decomposed.

Currently at the SDK level we just have the ability to PUT the schedules:

I propose that instead of extend(ttl) it's a set(expire_time) so the API is idempotent (retry resistant). We can still keep the "extend" verbiage in user-facing features.

I propose that instead of extend(ttl) it's a set(expire_time) so the API is idempotent (retry resistant). We can still keep the "extend" verbiage in user-facing features.

Nice, we're all in agreement - that's well thought out. I like how we get the best presentation and resource representation from that mechanism.

@johnstcn and I are going to go with that approach!

My current thought on the public-facing API of this is roughly:

curl 'http://$CODER/api/v2/workspaces/$WORKSPACE_ID/extend' \
  --request PUT \
  --header 'cookie: om nom nom' \
  --verbose \
  --data '{"deadline": "2022-05-24T17:59:59Z01:00"}'

Thoughts?

That API looks shiny clean to me.

Currently going with the following implementation (relevant Slack thread):

• Add field deadline to table workspace_builds.
• Upon inserting a row into workspace_builds, deadline will be set to now + workspace.ttl if workspace.ttl is set, and the zero time otherwise.
• Autostop will now check the deadline field of the workspace_build for the purpose of autostop logic.
• Adding a new route /api/v2/workspaces/:workspace/extend which will set the deadline of the currently active workspace build to the desired value.
  • The new deadline must be after the existing deadline, and not the zero time.
• Provisionerd will update workspace_build.deadline upon successful workspace build completion (equal to now plus workspace TTL, if it exists)