Add stale time config to InstanceProfileCredentialsProvider #5758
Conversation
…for refreshing credentials earlier due to stale value. This will help prevent returning invalid credentials when an error is encountered during asynchronous refresh.
…for refreshing credentials earlier due to stale value. This will help prevent returning invalid credentials when an error is encountered during asynchronous refresh.
|
| public ResourcesEndpointRetryPolicy retryPolicy() { | ||
| return new ContainerCredentialsRetryPolicy(); | ||
| } |
There was a problem hiding this comment.
I don't think we can add retry at this point for IMDS credentials provider because it may increase latency and break customers.
There was a problem hiding this comment.
right, that was a ask from Hadoop. Instead we can add it as an optional config as well
| @@ -174,7 +178,7 @@ private Instant staleTime(Instant expiration) { | |||
| return null; | |||
| } | |||
|
|
|||
| return expiration.minusSeconds(1); | |||
| return expiration.minus(staleTime); | |||
There was a problem hiding this comment.
I was trying to understand comment in #3314 (comment)
Looks like the 1 sec is intentional , if a user configures an excessively large stale time (e.g., expiration.minusMinutes(10)), credentials might be marked as stale too early, causing unnecessary refreshes and increased load on the credential provider. WDYT ?
There was a problem hiding this comment.
the default must be > the retry sleep delay of 10s. Otherwise when a call is throttled it is going to fail.
There was a problem hiding this comment.
you need to change that default to be > 10s; without that any 503 response is not going be recovered from.
Those of us who have encountered the problem will know to explicitly change it, but people who haven't yet hit it will only find out when things go wrong.
There is also the subtlety that all processes running in the same VM will be using the same timeout, as it is based on when the shared credentials expire. The more processes running, the more risk of that 503 -regardless of what the value is. This means that any constant value can create a Thundering Herd.
The "extra load" concern is marginal, given refresh time is every hour. spreading out that load is likely to be better as any herd-triggered retry is load in itself.
I'd suggest some larger number and maybe a jitter of a few seconds to spread out load from many processes.
| @@ -174,7 +178,7 @@ private Instant staleTime(Instant expiration) { | |||
| return null; | |||
| } | |||
|
|
|||
| return expiration.minusSeconds(1); | |||
| return expiration.minus(staleTime); | |||
There was a problem hiding this comment.
the default must be > the retry sleep delay of 10s. Otherwise when a call is throttled it is going to fail.
Add stale time config to
InstanceProfileCredentialsProviderto allow for refreshing credentials earlier due to stale value. This will help prevent returning invalid credentials when an error is encountered during asynchronous refresh.Motivation and Context
Fixes for #5247 , this will allow user to provide a higher value for prefetch to prevent returning expired credentails without changing default value. Increasing this value may lead to a higher rate of request to IMDS, so we ought to avoid changing the base default value for it.
Modifications
staleTimeconfiguration option toInstanceProfileCredentialsProviderInstanceProfileCredentialsProviderTesting
Added unit tests
Screenshots (if appropriate)
Types of changes