feat(cli): extend duration to longer units #15040
Conversation
cli/util_internal_test.go
Outdated
| {"10s", 10 * time.Second, true}, | ||
| {"1m", 1 * time.Minute, true}, | ||
| {"20h", 20 * time.Hour, true}, | ||
| {"10y10d10s", 0, false}, |
There was a problem hiding this comment.
I think users will expect durations like 1y1d to work here. It shouldn't be a huge lift to enable this!
There was a problem hiding this comment.
Hey @johnstcn I tried to play with time.ParseDuration golang function to mimic the behavior as much as possible - and changed to indeed modify what you've raised.
…o feat/improve-duration-flags
|
This is excellent @defelmnq. I suggest we stay uniform and check and update all durations of input throughput the product to support the string format across CLI/API/frontend. It doesn't have to be in this PR and can be tracked as a separate issue. |
cli/util.go
Outdated
| // - d (days) | ||
| // - y (years) |
There was a problem hiding this comment.
It may make sense to explicitly note that this will not take into account things like DST or leap years or all that other assorted wibbly wobbley timey wimey stuff.
| // - d (days) | |
| // - y (years) | |
| // - d (days, interpreted as 24 hours) | |
| // - y (years, interpreted as 8_760 hours) |
There was a problem hiding this comment.
My first though was about leap years too :)
There was a problem hiding this comment.
Yep - indeed we can document it. About the behavior are we good to keep it this way ? I felt like it can quickly become complicated with time saving, leap years etc.. otherwise - maybe we can do it in the follow-up PR in serpent if we want to use it everywhere.
There was a problem hiding this comment.
Yeah, definitely not a must-have
There was a problem hiding this comment.
I'm happy with a naive definition of days and years here. Adding DST / leap year awareness adds a lot of complications, as you need both a timezone and a relative time. We can add a follow-up issue if we think it's necessary though.
| {"1d", 24 * time.Hour, true}, | ||
| {"1y", 365 * 24 * time.Hour, true}, | ||
| {"10s", 10 * time.Second, true}, | ||
| {"1m", 1 * time.Minute, true}, | ||
| {"20h", 20 * time.Hour, true}, | ||
| {"10y10d10s", 10*365*24*time.Hour + 10*24*time.Hour + 10*time.Second, true}, | ||
| {"10ms", 10 * time.Millisecond, true}, | ||
| {"5y10d10s5y2ms8ms", 10*365*24*time.Hour + 10*24*time.Hour + 10*time.Second + 10*time.Millisecond, true}, | ||
| {"10yz10d10s", 0, false}, |
There was a problem hiding this comment.
question: What happens if we try to parse a duration greater than 2540400h10m10.000000000s (e.g. 1000y)?
(see: https://github.com/golang/go/blob/master/src/time/time.go#L954C21-L954C45)
| parsedLifetime, err = extendedParseDuration(tokenLifetime) | ||
| if err != nil { | ||
| return xerrors.Errorf("parse lifetime: %w", err) | ||
| } |
There was a problem hiding this comment.
suggestion: given that we have the token config available, we can check if the requested lifetime is greater than MaxTokenLifetime client-side. This may not be completely necessary though, as the API will disallow creating tokens with lifetime greater than MaximumTokenDuration. Dealer's choice!
There was a problem hiding this comment.
Yeah you're completely right - makes sense I just changed it a bit to handle the config fetched ! 👌
| @@ -46,7 +46,7 @@ func (r *RootCmd) tokens() *serpent.Command { | |||
|
|
|||
| func (r *RootCmd) createToken() *serpent.Command { | |||
| var ( | |||
| tokenLifetime time.Duration | |||
| tokenLifetime string | |||
There was a problem hiding this comment.
@defelmnq @johnstcn WDYT about defining a new type in coder/serpent, time.LongDuration?
There was a problem hiding this comment.
I created a follow-up issue here - would definitely be a cool one to do indeed.
cli/util.go
Outdated
| // - d (days) | ||
| // - y (years) |
There was a problem hiding this comment.
My first though was about leap years too :)
|
Hey @mtojek @johnstcn thanks a lot for the input here - really appreciate. Since the last review, here are globally the points I tried to change and improve :
What I would love to do as a follow-up :
|
This PR is a proposal to improve the situation described in #14750
For some precise commands - we would like to be able to use durations bigger than hours, minutes..
This PR extends the Duration proposed by Go with :
d- a day or 24hours.y- a year or 365 days.I also removed the default value for lifetime and instead fetch the maxLifetime value from codersdk - so by default if no value set we use the value defined in the config.