Skip to content

Disabling autostop causes workspace to get stuck with last autostop value #15390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
code-asher opened this issue Nov 6, 2024 · 5 comments
Closed

Disabling autostop causes workspace to get stuck with last autostop value #15390

code-asher opened this issue Nov 6, 2024 · 5 comments
Assignees
@DanielleMaywood
Labels
customer-reported Bugs reported by enterprise customers. Only humans may set this. s2 Broken use cases or features (with a workaround). Only humans may set this.

Comments

@code-asher
Copy link
Member

code-asher commented Nov 6, 2024 •
edited
Loading

To reproduce:

  1. Create a new template using the "Docker Containers" starter template (notice it does not allow customizing the autostop and has a default of 24 hours).
  2. Create a workspace using that template. The workspace must be created while autostop is currently enabled. Workspaces that are initially created with autostop disabled somehow do not have any problems updating correctly.
  3. Disable autostop in the template through the UI.
  4. Update the workspace, notice it will continue to say "stops in a day" despite autostop being disabled in the template, and showing as disabled in the workspace settings.
  5. New workspaces are fine and do not have any autostop.

I think the default autostop gets set on the workspace, but when you disable autostop it does not then remove it from the workspaces, and you cannot change it as a user either because autostop is disabled in this scenario.
@coder-labeler coder-labeler bot added bug risk Prone to bugs needs-triage Issue that require triage labels Nov 6, 2024
@matifali matifali added s2 Broken use cases or features (with a workaround). Only humans may set this. customer-reported Bugs reported by enterprise customers. Only humans may set this. and removed bug risk Prone to bugs needs-triage Issue that require triage labels Nov 6, 2024
@code-asher
Copy link
Member Author

code-asher commented Nov 7, 2024 •
edited
Loading

Also, not sure if this is a bug but it feels a little unexpected to me, if you set the default to zero then no workspaces will autostop (expected), then later set the default to 24 all workspaces will autostop after 24 hours (expected), then later again enable customizing autostop, some workspaces may have no autostop depending on what the default was when they were created (unexpected?). I think I would expect them to all still have 24 hours.

Probably caused by the same thing. Without having seen the code, my guess is maybe we have to go through and update autostop in the DB on all workspaces when the template default changes?

@johnstcn
Copy link
Member

cc @bpmct should we add this to the upcoming sprint? Possible 🥥 issue

@DanielleMaywood DanielleMaywood mentioned this issue Dec 5, 2024
Merged
DanielleMaywood added a commit that referenced this issue Dec 6, 2024
@DanielleMaywood
fix: update workspace TTL on template TTL change (#15761)
40624bf 
Relates to #15390

Currently when a user creates a workspace, their workspace's TTL is
determined by the template's default TTL. If the Coder instance is AGPL,
or if the template has disallowed the user from configuring autostop,
then it is not possible to change the workspace's TTL after creation.
Any changes to the template's default TTL only takes effect on _new_
workspaces.

This PR modifies the behaviour slightly so that on AGPL Coder, or on
enterprise when a template does not allow user's to configure their
workspace's TTL, updating the template's default TTL will also update
any workspace's TTL to match this value.
@DanielleMaywood
Copy link
Contributor

With #15761 being merged, when a template's TTL is modified, and users are unable to change their workspace's autostop, then workspaces using this template have their TTL modified.

This doesn't have an effect on running workspaces though. As an example, if a workspace was started when autostop was 8 hours, and then the template admin decided to disable autostop, the running workspace still has the same 8 hour deadline. Only when the workspace is next started does this take effect.

A question I have is do we want to modify a running workspace's deadline based on the changing TTL or do we leave that as is? My thoughts are that if the TTL is increased then there is no harm in extending the workspace's deadline, but I'm not sure if it is a good user experience to decrease a workspace's deadline when the TTL is decreased. @bpmct I feel like this might need product's perspective.

@bpmct
Copy link
Member

bpmct commented Dec 9, 2024 •
edited
Loading

A question I have is do we want to modify a running workspace's deadline based on the changing TTL or do we leave that as is? My thoughts are that if the TTL is increased then there is no harm in extending the workspace's deadline, but I'm not sure if it is a good user experience to decrease a workspace's deadline when the TTL is decreased. @bpmct I feel like this might need product's perspective.

I totally agree with you here. We should never allow a bulk change to decrease a living workspaces' autostop. Increasing is fine, but I am also totally OK if we just require an update for the changes to take effect. Will defer to your judgement here.

Bulk workspace actions or CLIs can be used to update workspaces.

@DanielleMaywood
Copy link
Contributor

Thanks! I think for now we should leave the running workspaces' deadline as is then.

aslilac pushed a commit that referenced this issue Dec 11, 2024
@DanielleMaywood @aslilac
fix: update workspace TTL on template TTL change (#15761)
45862a7 
Relates to #15390

Currently when a user creates a workspace, their workspace's TTL is
determined by the template's default TTL. If the Coder instance is AGPL,
or if the template has disallowed the user from configuring autostop,
then it is not possible to change the workspace's TTL after creation.
Any changes to the template's default TTL only takes effect on _new_
workspaces.

This PR modifies the behaviour slightly so that on AGPL Coder, or on
enterprise when a template does not allow user's to configure their
workspace's TTL, updating the template's default TTL will also update
any workspace's TTL to match this value.
@DanielleMaywood DanielleMaywood mentioned this issue Dec 19, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DanielleMaywood DanielleMaywood

Labels
customer-reported Bugs reported by enterprise customers. Only humans may set this. s2 Broken use cases or features (with a workaround). Only humans may set this.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@johnstcn @matifali @bpmct @DanielleMaywood @code-asher