Skip to content

feat: update workspace deadline when workspace ttl updated #2165

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 20 commits into from
Jun 9, 2022

Conversation

johnstcn
Copy link
Member

@johnstcn johnstcn commented Jun 8, 2022

This PR adds the following changes:

  • CLI: updating a workspace TTL updates the deadline of the workspace.
    • If the TTL is being un-set, the workspace deadline is set to zero.
    • If the TTL is being set, the workspace deadline is updated to be the last updated time of the workspace build plus the requested TTL. Additionally, the user is prompted to confirm interactively (can be bypassed with -y).
  • UI: updating the workspace schedule behaves similarly to the CLI, showing a message to the user if the updated TTL/time to shutdown would effect changes to the lifetime of the running workspace.

Closes #1783

@johnstcn johnstcn self-assigned this Jun 8, 2022
@johnstcn johnstcn marked this pull request as ready for review June 9, 2022 10:49
@johnstcn johnstcn requested a review from a team as a code owner June 9, 2022 10:49
@johnstcn johnstcn requested review from a team and greyscaled June 9, 2022 10:49
Comment on lines +101 to +108
_, err = cliui.Prompt(cmd, cliui.PromptOptions{
Text: fmt.Sprintf(
"Workspace %q will be stopped %s. Are you sure?",
workspace.Name,
humanRemaining,
),
Default: "yes",
IsConfirm: true,
Copy link
Member Author

Choose a reason for hiding this comment

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

review: we can skip the prompt if timeRemaining >= SOME_CUTOFF.

Comment on lines +726 to +728
if testCase.expectedDeadline != nil {
require.WithinDuration(t, *testCase.expectedDeadline, updated.LatestBuild.Deadline, time.Minute, "expected autostop deadline to be equal expected")
}
Copy link
Member Author

Choose a reason for hiding this comment

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

review: I'm fudging a bit here out of necessity as the provision step can take a while with a test database.

}

export interface WorkspaceScheduleFormProps {
fieldErrors?: FieldErrors
initialValues?: WorkspaceScheduleFormValues
isLoading: boolean
now: dayjs.Dayjs
Copy link
Member Author

Choose a reason for hiding this comment

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

review: I'm not sure if there's a better way to do it, but I figured it's easiest to just pass in the current time as a prop.

Copy link
Contributor

Choose a reason for hiding this comment

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

Comment(approving): I'm OK with this, it seems like we either don't do this and wrestle with mocks or spies in tests and storybook...or we just do this and live with it being a little weird.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion(nit): Just let's make it optional:

Suggested change
now: dayjs.Dayjs
now?: dayjs.Dayjs

Copy link
Member

@mafredri mafredri left a comment

Choose a reason for hiding this comment

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

Clean change! I had one question but otherwise LGTM (backend)


if latestBuild.UpdatedAt.IsZero() {
// Build in progress; provisionerd should update with the new TTL.
return nil
Copy link
Member

Choose a reason for hiding this comment

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

Question: What happens if a user starts a workspace with one TTL, but tries to update the TTL before the build is complete? As a user, I'd expect the new TTL to be in-effect once the build has completed or receive an error that TTL cannot be updated (yet).

Copy link
Member Author

Choose a reason for hiding this comment

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

See

workspaceDeadline = now.Add(time.Duration(workspace.Ttl.Int64))
-- we fetch the workspace TTL in a transaction and update the deadline upon finishing the provisioner job.

  • If the user updates the TTL first, then the updated TTL will be used by provisionerd.
  • If provisionerd updates the TTL first, then the deadline should be updated.

Copy link
Member

Choose a reason for hiding this comment

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

Ooh yeah that makes sense, thanks for clarifying!

return `⚠️ ${Language.ttlCausesShutdownHelperText} ${Language.ttlCausesShutdownSoon} ⚠️`
}
const newDeadlineString = newDeadline.tz(tz).format("hh:mm A z")
return `${Language.ttlCausesShutdownHelperText} ${Language.ttlCausesShutdownAt} ${newDeadlineString}.`
Copy link
Member

Choose a reason for hiding this comment

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

NIT: would making the Language value a function alleviate the need for some of these keys? Example:

const Language = {
  ttlCausesShutdownAtText: (newDeadlineString: string): string => {
    return `Your workspace will shut down at ${newDeadlineString}`
  },
}

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 guess it would, but it would make the Language portion more complex. I feel like we'd want to keep Language as a simple lookup table and keep the complexity close to where it's used. I'm fine with going either way though if folks have strong opinions about it!

Copy link
Member

Choose a reason for hiding this comment

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

No strong opinions here - that sounds good to me!

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.

nice work! ✔️ for FE

Comment on lines +97 to +106
humanRemaining := "in " + timeRemaining.String()
if timeRemaining <= 0 {
humanRemaining = "immediately"
}
_, err = cliui.Prompt(cmd, cliui.PromptOptions{
Text: fmt.Sprintf(
"Workspace %q will be stopped %s. Are you sure?",
workspace.Name,
humanRemaining,
),
Copy link
Contributor

Choose a reason for hiding this comment

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

praise: wonderful strings!

@@ -550,19 +550,16 @@ func TestWorkspaceUpdateAutostart(t *testing.T) {
name: "invalid location",
schedule: ptr.Ref("CRON_TZ=Imaginary/Place 30 9 * * 1-5"),
expectedError: "parse schedule: provided bad location Imaginary/Place: unknown time zone Imaginary/Place",
// expectedError: "status code 500: Invalid autostart schedule\n\tError: parse schedule: provided bad location Imaginary/Place: unknown time zone Imaginary/Place",
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Are these leftover debug?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, left over from some previous PR where they snuck in!

Example.args = {
export const WorkspaceNotRunning = Template.bind({})
WorkspaceNotRunning.args = {
now: dayjs("2022-05-17T17:40:00Z"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Praise: Thank you for making this constant.

}

export interface WorkspaceScheduleFormProps {
fieldErrors?: FieldErrors
initialValues?: WorkspaceScheduleFormValues
isLoading: boolean
now: dayjs.Dayjs
Copy link
Contributor

Choose a reason for hiding this comment

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

Comment(approving): I'm OK with this, it seems like we either don't do this and wrestle with mocks or spies in tests and storybook...or we just do this and live with it being a little weird.

}

export interface WorkspaceScheduleFormProps {
fieldErrors?: FieldErrors
initialValues?: WorkspaceScheduleFormValues
isLoading: boolean
now: dayjs.Dayjs
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion(nit): Just let's make it optional:

Suggested change
now: dayjs.Dayjs
now?: dayjs.Dayjs

greyscaled added a commit that referenced this pull request Jun 9, 2022
This does not finish all tasks in #2175 but is one of the asks.

@johnstcn - you should do the same lowercasing of HH->hh in #2165
@johnstcn johnstcn requested a review from greyscaled June 9, 2022 19:51
@greyscaled
Copy link
Contributor

ah crud I created a conflict for you @johnstcn :(

@johnstcn
Copy link
Member Author

johnstcn commented Jun 9, 2022

ah crud I created a conflict for you @johnstcn :(

s'alright!

@johnstcn johnstcn merged commit 119db78 into main Jun 9, 2022
@johnstcn johnstcn deleted the cj/1783/updating-workspace-ttl-updates-deadline branch June 9, 2022 21:10
kylecarbs pushed a commit that referenced this pull request Jun 10, 2022
This commit adds the following changes to workspace scheduling behaviour:

* CLI: updating a workspace TTL updates the deadline of the workspace.
  * If the TTL is being un-set, the workspace deadline is set to zero.
  * If the TTL is being set, the workspace deadline is updated to be the last updated time of the workspace build plus the requested TTL. Additionally, the user is prompted to confirm interactively (can be bypassed with -y).
* UI: updating the workspace schedule behaves similarly to the CLI, showing a message to the user if the updated TTL/time to shutdown would effect changes to the lifetime of the running workspace.
johnstcn added a commit that referenced this pull request Jun 14, 2022
This commit makes the following changes:

- Partially reverts the changes of feat: update workspace deadline when workspace ttl updated #2165, making the deadline of a running workspace build independant of TTL, once started.
- CLI: updating a workspace TTL no longer updates the deadline of the workspace.
- UI: updating a workspace TTL no longer updates the deadline of the workspace.
- Drive-by: API: When creating a workspace, default TTL to min(12 hours, template max_ttl) if not instructed otherwise.
- Drive-by: CLI: list: measure workspace extension correctly (+X in last column) from the time the provisioner job was completed
- Drive-by: WorkspaceSchedule: show timezone of schedule if it is set, defaulting to dayjs guess otherwise.
- Drive-by: WorkspaceScheduleForm: fixed an issue where deleting the "TTL" value in the form would show the text "Your workspace will shut down a few seconds after start".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

If you update 'time until shutdown' in a running workspace, the workspace UI has the old value
4 participants