IMDS timeout increased to 10 seconds

[shashanksbs45]

In case of stressed servers 1000ms is very aggressive time. This PR is to just trying to get some attention in to this intermittent context deadline issue. Error Im facing is ManagedIdentityCredential: IMDS token request timed out error for long running jobs that makes many requests to azure secrets fetch data.

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to CHANGELOG.md are included.
• MIT license headers are included in each file.

[ghost]

Thank you for your contribution shashanksbs! We will review the pull request and get back to you soon.

[chlowell]

Thanks, this is timely! We (Azure SDK authentication team) recently began discussing ways to improve IMDS timeout behavior for DefaultAzureCredential. Simply lengthening the timeout is one of the options but would regress performance in some scenarios, and I don't want to make any changes here until we've explored other options. Note that only DefaultAzureCredential imposes this timeout. If it's a problem in your application, you can avoid it by using ManagedIdentityCredential directly or with ChainedTokenCredential.

To give some context on the timeout, we added it to limit the worst case running time of DefaultAzureCredential's first auth attempt. This is important when IMDS isn't available, for example in local development. The only way to learn whether IMDS is available is to try connecting to it, which can take longer than 10 seconds to time out on some platforms.

[shashanksbs45]

@chlowell @jhendrixMSFT @kenegozi
how ManagedIdentityCredential or ChainedTokenCredential helpful in mitigating IMDS timeout issue

Pod Identity can take up to a couple minutes to get ready for token requests from new pods. In case of clients that have shorter timeouts, the retries can be terminated and the client will not receive a token in the first attempt. This feature flag can use to prevent timeouts due to that delay. we added https://azure.github.io/aad-pod-identity/docs/configure/feature_flags/#set-retry-after-header-in-nmi-response this check in azure pod identity helm chart.

But IMDS timeout issue still persists and sometimes we are getting no default identity is assigned to this resource error.

these errors occur mostly on stressed servers, on normal day it works fine

Please suggest any resolution for this

[jhendrixMSFT]

The short timeout that you're changing here is only part of DefaultAzureCredential. If you directly use ManagedIdentityCredential then there is no timeout (outside of how the default HTTP client works).

[ghost]

Hi @realDeveloper45. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ghost]

Hi @realDeveloper45. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass.