Skip to content

feat: add inactivity cleanup and failure cleanup configuration fields to Template Schedule Form #7402

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 24 commits into from
May 5, 2023

Conversation

Kira-Pilot
Copy link
Member

@Kira-Pilot Kira-Pilot commented May 4, 2023

Resolves #7346 and resolves #7347.
#7401 will be a fast follow. Spoke with Ben - we will not be adding these fields to the new template form at the moment.

Run locally via CODER_EXPERIMENTS='workspace_actions' ./scripts/develop.sh

Some notes:

  • I took out the workspace_actions feature. I feel like for now, this feature can live under the codersdk.FeatureAdvancedTemplateScheduling entitlement. It is still feature flagged separately with a new experiment (workspace_actions)
  • I am using 14 days as a default value for both "Failure Cleanup" and "Inactivity Cleanup". @bpmct does this seem reasonable? Changed to 7 and 180 respectively as per Ben's comment.

Demo
Loom Link

Auditing works, too:
Screenshot 2023-05-03 at 5 33 14 PM

@bpmct
Copy link
Member

bpmct commented May 4, 2023

I am using 14 days as a default value for both "Failure Cleanup" and "Inactivity Cleanup". @bpmct does this seem reasonable?

Let's set "7 days" as a default for failure cleanup when enabled. And "180 days" for inactivity cleanup. It's pretty arbitrary, but here's my thinking:

  • A developer who hasn't used their workspace for 6 months definitely doesn't need it anymore, unless it's for a project they rarely touch. However, there are many workspaces I go 2 weeks without using if its not my primary project.
  • 7 days before stopping failed workspaces gives the operator time to hop in the logs and troubleshoot if needed.

And an admin can always tweak these, but I'd rather default to something more conservative and allow the admin to add more aggressive settings. After all, its disabled by default.

@Kira-Pilot Kira-Pilot added this to the Workspace Actions GA milestone May 4, 2023
@Kira-Pilot Kira-Pilot requested a review from BrunoQuaresma May 4, 2023 14:45
Copy link
Collaborator

@BrunoQuaresma BrunoQuaresma left a comment

Choose a reason for hiding this comment

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

The FE code looks good to me

@Kira-Pilot Kira-Pilot requested a review from deansheather May 4, 2023 15:21
}, nil
}

func (*enterpriseTemplateScheduleStore) SetTemplateScheduleOptions(ctx context.Context, db database.Store, tpl database.Template, opts schedule.TemplateScheduleOptions) (database.Template, error) {
if int64(opts.DefaultTTL) == tpl.DefaultTTL &&
int64(opts.MaxTTL) == tpl.MaxTTL &&
int64(opts.FailureTTL) == tpl.FailureTTL &&
int64(opts.InactivityTTL) == tpl.InactivityTTL &&
Copy link
Member Author

Choose a reason for hiding this comment

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

@deansheather I see us making what looks like a duplicate check in the patchTemplateMeta handler - curious why we need to check at all (I don't see us doing this in other routes) and also why we need to check twice, once in the handler and once in the store.

Copy link
Member

Choose a reason for hiding this comment

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

You're right this does seem unnecessary and can probably be removed from the handlers and just kept in the store. Make sure the AGPL version of the store has the equivalent check though (but only for the AGPL-permitted fields)!

Copy link
Member Author

Choose a reason for hiding this comment

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

Great, will handle that in a follow-up!

Copy link
Member

@deansheather deansheather left a comment

Choose a reason for hiding this comment

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

BE looks good, I'm glad you could use of the TemplateScheduleStore interface for this

}, nil
}

func (*enterpriseTemplateScheduleStore) SetTemplateScheduleOptions(ctx context.Context, db database.Store, tpl database.Template, opts schedule.TemplateScheduleOptions) (database.Template, error) {
if int64(opts.DefaultTTL) == tpl.DefaultTTL &&
int64(opts.MaxTTL) == tpl.MaxTTL &&
int64(opts.FailureTTL) == tpl.FailureTTL &&
int64(opts.InactivityTTL) == tpl.InactivityTTL &&
Copy link
Member

Choose a reason for hiding this comment

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

You're right this does seem unnecessary and can probably be removed from the handlers and just kept in the store. Make sure the AGPL version of the store has the equivalent check though (but only for the AGPL-permitted fields)!

Kira-Pilot and others added 2 commits May 5, 2023 07:19
…wn.sql

Co-authored-by: Dean Sheather <dean@deansheather.com>
….sql

Co-authored-by: Dean Sheather <dean@deansheather.com>
@Kira-Pilot Kira-Pilot merged commit 5ffa6da into main May 5, 2023
@Kira-Pilot Kira-Pilot deleted the workspace-actions-template-route/kira-pilot branch May 5, 2023 15:19
@github-actions github-actions bot locked and limited conversation to collaborators May 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants