-
Notifications
You must be signed in to change notification settings - Fork 74k
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
Unnecessary logging noise for non-authenticated GCS access #25464
Comments
Currently, when attempting to fetch an object from GCS, TF will attempt to detect the GCE metadata service, and (if available) use the metadata service for fetching auth tokens. However, in many environments (such as Colab), all attempts to reach the metadata service will fail by timing out. TF will valiantly retry, leading to a situation where calling `tf.io.gfile.exists('gs://some-public-bucket')` will take almost 700s (!) to finish all retries. Once these retries complete, we attempt the request with an empty bearer token, and the request succeeds. Once the request succeeds, TF sets an indefinite expiration time, meaning that an interactive user can't (say) call `gcloud auth` and try again. This change addresses this problem by adding a new hook for completely skipping the GCE credential fetch, in the form of the `$NO_GCE_CHECK` environment variable. This already exists in other Google auth libraries, eg the Java client: https://github.com/googleapis/google-auth-library-java/blob/999de3b11de320354a8ff80a8dc906723d708cf4/oauth2_http/java/com/google/auth/oauth2/DefaultCredentialsProvider.java#L79 When set to any value (even the empty string), the google auth provider completely skips attempts to talk to the GCE metadata service. In addition, we don't set an indefinite expiration time in this case, so that future attempts to fetch credentials aren't skipped. Fixes #25463. (At least, provides the hook for Colab to use.) Offers one potential solution to #25464. PiperOrigin-RevId: 232800897
My fix in a252fe8 adds a hook to avoid the "unnecessary access" part of this bug; we still get noisier logs than I'd like. I'm going to repurpose this issue for "make logs less chatty for expected retries". |
@rsepassi Can you please confirm if the issue is being solved with the above comment. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you. |
Closing as stale. Please reopen if you'd like to work on this further. |
System information
Describe the current behavior
Unnecessary access to GCP metadata endpoint, 10 retries, and lots of logging.
Describe the expected behavior
Should not be trying to access GCP metadata endpoint.
Code to reproduce the issue
(Linking issue tensorflow/datasets#38)
The text was updated successfully, but these errors were encountered: