-
Notifications
You must be signed in to change notification settings - Fork 881
CLI auto-stop extension #1461
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
Comments
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: Lines 313 to 315 in 7bb7c6c
|
Please add your planning poker estimate with ZenHub @johnstcn |
@johnstcn I'll slot this one for next sprint so that it can land in grooming this week. This gives us some time to tackle other stories and then co-focus on extension in that sprint. |
I'm going to call the CLI command bump |
Closed by #1828 |
Verified in Coder v0.0.0-devel+af401e3 |
User Story 👥
As a user with a workspace that has a ttl, I'd like to use the CLI to extend my lease.
Details
There are two types of extension scenarios: reactive and pre-emptive. Underneath the hood,
these are effectively the same and can be re-worded as: "I may extend well before shutdown, or as a CTA
when my lease is almost up (example via notification)".
Reactive Extension in a CLI-only approach
When we notify users that their workspace is shutting down (ie: #1414 ), we might give instructions or a
CTA.
Pre-emptive Extension ina CLI-only approach
We may expose an extension command that looks something like:
If
[time]
is not supplied, we default to90 mins
.[time]
may optionally be specified. We should setan upper bound on
[time]
. TBD what that upper bound is, but at least two approaches are:Acceptance Criteria
The text was updated successfully, but these errors were encountered: