Skip to content

feat: add template max_ttl #6114

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.

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

Merged
merged 32 commits into from
Mar 7, 2023
Merged

feat: add template max_ttl #6114

merged 32 commits into from
Mar 7, 2023

Conversation

deansheather
Copy link
Member

@deansheather deansheather commented Feb 8, 2023

Adds an optional max TTL setting to templates. This value will apply to workspaces after they are restarted (similarly to how scheduling changes only apply after restart).

  • Adds max_ttl (alongside the existing default_ttl) in the templates table.
  • Adds max_deadline to the workspace_builds table, which is set to time.Now().Add(template.maxTTL) if the template has a max TTL set.
  • During bump operations (either activity bump or manual TTL bump) ensure that the new deadline is sooner than the max deadline.

TODO:

  • Block disabling TTL if template has a max TTL
  • Enterprise-licensed code for setting the template max TTL
  • Dashboard
  • Dashboard alpha tag
  • CLI (marked alpha)
  • Update workspace TTLs for all workspaces on template update
  • Tests

Closes #6047

@bpmct bpmct mentioned this pull request Feb 15, 2023
@deansheather deansheather force-pushed the dean/schedule-max-ttl branch from 37d4193 to e28e32e Compare March 1, 2023 17:55
@deansheather deansheather marked this pull request as ready for review March 1, 2023 20:30
Copy link
Member

@mtojek mtojek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well done, Dean 👍

I left a few comments about package segregation. My main concern is rather a strong dependency between coderd and provisionerdserver, but would like to hear more feedback around this.

cmd.Flags().StringVarP(&description, "description", "", "", "Edit the template description.")
cmd.Flags().StringVarP(&icon, "icon", "", "", "Edit the template icon path.")
cmd.Flags().DurationVarP(&defaultTTL, "default-ttl", "", 0, "Edit the template default time before shutdown - workspaces created from this template default to this value.")
cmd.Flags().DurationVarP(&maxTTL, "max-ttl", "", 0, "Edit the template maximum time before shutdown - workspaces created from this template must shutdown within the given duration after starting. This is an enterprise-only feature.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an enterprise-only feature

nit: do we need to mention it? If we decide to open this feature to the OSS audience, it would be misleading. I'm not sure what's the rule of thumb for enterprise features in general.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems weird to not mention it if it's a licensed feature, otherwise people will try --max-ttl and see errors. The frontend does something similar, by showing the box but disabling it and adding a "enterprise" label

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it common for other flags? I might have missed it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have done it for deployment config flags before but I'm unsure if we've done it for CLI flags.


// TemplateScheduleStore provides an interface for retrieving template
// scheduling options set by the template/site admin.
type TemplateScheduleStore interface {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering why is TemplateScheduleStore an interface. I see only one implementation here: agplTemplateScheduleStore. Is it for testing purposes?

Ok, I see now, there is one for enterprise too.

WDYT about renaming stores to be more descriptive instead of agpl... and enterprise.... If we decide to introduce another pricing plan, then we will need to rename them accordingly :) I would move these implementations to a seperate package, maybe schedule or scheduling?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently have a schedule package but it's under autobuild/schedule, whereas this package doesn't pertain to autostart at all, only autostop...

Maybe I should move the existing schedule package to coderd/schedule and then copy this code to it instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is done, I've moved coderd/autobuild/schedule to coderd/schedule and added the code from this file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not entirely what I meant. Currently, the agpl... and enterprise... logic are scattered. The idea is place them in the same package, but rename accordingly. These are just different strategies, so it's perfectly fine to keep them together.

For instance, agplTemplateScheduleStore -> userControlledTemplateScheduleStore, enterpriseTemplateScheduleStore -> maxTTLTemplateScheduleStore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot place them in the same package as AGPL code can't be mixed with enterprise code, and there needs to be an implementation outside of AGPL otherwise AGPL-compiled binaries wouldn't be able to compile properly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change the names of them but I feel the names you propose are too specific especially if we add other features to them in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, that's unfortunate. Let's leave as is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same pattern we use for other enterprise features that hide behind interfaces btw

}

return provisionerdserver.TemplateScheduleOptions{
// TODO: make configurable at template level
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow-up issue?

"defaultTTLHelperText_other": "Workspaces will default to stopping after {{count}} hours.",
"maxTTLHelperText_zero": "Workspaces may run indefinitely.",
"maxTTLHelperText_one": "Workspaces must stop within 1 hour of starting.",
"maxTTLHelperText_other": "Workspaces must stop within {{count}} hours of starting.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

Copy link
Member

@Kira-Pilot Kira-Pilot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really nice work on the FE

@deansheather
Copy link
Member Author

@Kira-Pilot I won't take credit for the FE, Bruno tidied it up for me :D

@mtojek mtojek self-requested a review March 3, 2023 11:58
Copy link
Member

@mtojek mtojek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@deansheather deansheather enabled auto-merge (squash) March 6, 2023 18:26
@deansheather deansheather merged commit 66a6b59 into main Mar 7, 2023
@deansheather deansheather deleted the dean/schedule-max-ttl branch March 7, 2023 14:15
@github-actions github-actions bot locked and limited conversation to collaborators Mar 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

scheduling: advanced scheduling controls
4 participants