Opportunistic token refresh (for BitBucket Server) #19715
Conversation
| @@ -1852,8 +1854,8 @@ export class WorkspaceStarter { | |||
| targetMode = CloneTargetMode.REMOTE_HEAD; | |||
| } | |||
|
|
|||
| const tokenValidityThreshold = (await isLongAccessTokenValidityThresholdEnabled(user)) ? 50 : 30; | |||
There was a problem hiding this comment.
The default for "start workspace" was 30 minutes before. We are reducing to 10 here, but can adjust any time with the new feature flag.
|
|
||
| @injectable() | ||
| export class TokenService implements TokenProvider { | ||
| static readonly GITPOD_AUTH_PROVIDER_ID = "Gitpod"; | ||
| static readonly DEFAULT_EXPIRY_THRESHOLD = 5; | ||
| /** [mins] */ | ||
| static readonly DEFAULT_LIFETIME = 5; |
There was a problem hiding this comment.
Since we explicitly pass in the long value in workspace start situation, I think the default should be small. OTOH making this rather small would trigger refreshes more often, which doesn't seem good. Maybe worth writing a comment about these implications for our future selves?
There was a problem hiding this comment.
Alternatively we could make this rather small, but only start opportunistic refreshes when expiry is in e.g 30m
There was a problem hiding this comment.
OTOH making this rather small would trigger refreshes more often, which doesn't seem good.
This is only true if we don't guess the estimated lifetime correctly, no? And only use SCM tokens transitively, except for the Workspaces case where we use a custom lifetime.
Alternatively we could make this rather small, but only start opportunistic refreshes when expiry is in e.g 30m
Not sure I understand: Wouldn't that remove all the benefits we are getting from this approach in the first place? 🤷
I get that we have the additional restriction, but I can't imagine this being worth it.
I'd say let's try this out in practice, and if we can tune the parameters to make it work for BBS.
|
We'll wait until Monday with merging. |
|
/unhold |
Description
This aims to introduce a new feature for token refreshes with SCMs dubbed "opportunistic refresh". If the feature flag is enabled, AND the SCM requires it (for now only BitBucket Server!), we ask for a fresh token whenever we "safely" can.
This "safely" is determined by us storing a new
reservedUntilDatewith each SCM token, with is set/updated whenever we re-use a token. This way, whenever we do a lookup on a SCM token, we know whether we can safely refresh it or not.Operational controls:
workspace_start_scm_access_token_lifetimefeature flag which controls the requested lifetime of a SCM tokenopportunistic_token_refreshfeature flag which controls whether "opportunistic refresh" is enabled at allgitpod_scm_token_refresh_requests_totalmetric with a new labelopportunisticRefresh("true" | "false" | "reserved")Related Issue(s)
Fixes ENT-4
How to test
kubectl logs server-5d5cdb8db5-tj9bl -f | grep "Token refreshed"and noticed how values changeDocumentation
Preview status
gitpod:summary
Build Options
Build
Run the build with werft instead of GHA
Run Leeway with
--dont-testPublish
Installer
Add desired feature flags to the end of the line above, space separated
Preview Environment / Integration Tests
If enabled this will build
install/previewIf enabled this will create the environment on GCE infra
Saves cost. Untick this only if you're really sure you need a non-preemtible machine.
Valid options are
all,workspace,webapp,ide,jetbrains,vscode,ssh. If enabled,with-previewandwith-large-vmwill be enabled./hold