Skip to content

Conversation

gustavovnicius
Copy link

Description:

Enhancement - Try resolving GOOGLE_CLOUD_PROJECT value using google-cloud-sdk.

Having a mandatory GOOCLE_CLOUD_PROJECT configuration is unnecessary, given the extension already depends on ADC context existing. It can try to infer the project from it.
Still mandatory to have a project id, but this gives more flexibility in the usage of the extension.

Existing Issue(s):
#2102

Testing:

Refactored the project id resolver logic into a separate method, including the more comprehensive ServiceOptions resolver. Tested the method for both the current strategy and falling back to ServiceOptions, also added a missing test for not being able to find the option and throwing an exception.

Documentation:

GOOGLE_CLOUD_PROJECT configuration was moved into the optional config section, with a note that even though it's optional, the extension needs it either provided or being able to infer it.

Outstanding items:

N/A

@gustavovnicius gustavovnicius requested a review from a team as a code owner August 15, 2025 13:13
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 15, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

  • ✅ login: gustavovnicius / name: Gustavo Bastos (5becf5e)

@otelbot-java-contrib
Copy link
Contributor

❌ The result from spotlessApply could not be committed to the PR branch, see logs: https://github.com/open-telemetry/opentelemetry-java-contrib/actions/runs/16990756319.

@otelbot-java-contrib
Copy link
Contributor

❌ The result from spotlessApply could not be committed to the PR branch, see logs: https://github.com/open-telemetry/opentelemetry-java-contrib/actions/runs/16990824329.

@gustavovnicius
Copy link
Author

Any outstanding blocker about this one?

@trask
Copy link
Member

trask commented Oct 7, 2025

cc @psx95 @jsuereth

@gustavovnicius gustavovnicius force-pushed the main branch 2 times, most recently from c0929d4 to 46f24dd Compare October 8, 2025 18:59
@psx95
Copy link
Contributor

psx95 commented Oct 8, 2025

Any outstanding blocker about this one?

Thanks for the PR @gustavovnicius! My only concern here is to take on the additional google-cloud-core dependency. My reasons behind this are -

  • google-cloud-core is a huge dependency and pulls in additional transitive dependency for an artifact that is supposed to be light-weight and currently only has a single dependency.
  • I think this problem should be solved at the google-auth-library-java level seeing as other language implementations for this library have already solved this issue (e.g. Python, Golang).

I am engaging internally with the folks maintaining the auth library to see if this request can be resolved at the Java auth library level.

@gustavovnicius
Copy link
Author

Thanks for the thoughtful feedback, @psx95 totally agree that we should be cautious with new dependencies.

I did a quick dependency analysis to verify the real impact of adding google-cloud-core.
The entire resolved dependency set it introduces is:

com.google.api.grpc:proto-google-common-protos:2.61.3  
com.google.api.grpc:proto-google-iam-v1:1.56.3  
com.google.api:api-common:2.53.3  
com.google.api:gax:2.70.3  
com.google.auth:google-auth-library-oauth2-http:1.39.1  
com.google.protobuf:protobuf-java-util:4.32.1  
com.google.protobuf:protobuf-java:4.32.1  
org.threeten:threetenbp:1.7.0

That’s ~8 small, standard Google client libraries already present in most GCP integrations, not a large footprint (roughly < 1 MB of total JARs), there's a big overlap with transient dependencies of google-auth-library-java.

I agree it would be ideal if google-auth-library-java natively provided this piece, and I’m all for following up upstream. But in the meantime, this dependency to me seems like a low-impact one.
Happy to adjust if the maintainers of google-auth-library-java do end up incorporating this functionality directly.

Another thought is regarding downstream adoption: Without it, the extension in some situations is virtually useless, as the sheer amount of changes and effort to adopt it across the board, far outweighs the extension.

@psx95
Copy link
Contributor

psx95 commented Oct 9, 2025

@gustavovnicius, while the number of JARs being pulled is only 8, most of them are not being used (the auth library being the exception) and while the combined size of them is 1MB which might look small, it is extremely huge when you compare it to the size of this artifact's JAR itself which is roughly ~10KB.

FWIW, I do agree that this is a fair ask and there is already a draft PR to expose the Project ID from the Auth Library.

I think we should follow the progress of this draft PR and make changes in this extension once the feature is available.

@gustavovnicius gustavovnicius changed the title [gcp-auth-extension]: Try resolving GCP_PROJECT with ServiceOptions if not provided [gcp-auth-extension]: Try resolving GCP_PROJECT from Google credentials if not provided Oct 15, 2025
@gustavovnicius gustavovnicius requested a review from laurit October 15, 2025 18:14
@gustavovnicius
Copy link
Author

New version has been adopted and project id is attempted to be resolved based on credentials. @psx95

Copy link
Contributor

@psx95 psx95 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!
Left a couple of suggestions that might be helpful.

- This is a required option, the agent configuration will fail if this option is not set.

#### Optional Config
- If neither of these options are set, the extension will attempt to infer the project id from the credentials used, however notice that not all credentials implementations will be able to provide a project id, so the inference is only a best-effort attempt.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- If neither of these options are set, the extension will attempt to infer the project id from the credentials used, however notice that not all credentials implementations will be able to provide a project id, so the inference is only a best-effort attempt.
- If neither of these options are set, the extension will attempt to infer the project id from the current credentials as a fallback, however notice that not all credentials implementations will be able to provide a project id, so the inference is only a best-effort attempt.

* @return The Google Cloud Project ID.
*/
@Nonnull
static String getGoogleProjectId(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do away with this functions since much of this functionality is already available in ConfigurableOption class.

See suggestion for customizeResource method.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@psx95, this method was added mostly so we could isolate the project id resolution in the tests.
Any suggestions for that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @gustavovnicius, this method is an implementation detail of the class and should have been private. For testing, I think you should test the expected behavior instead of testing the method in isolation. I think testQuotaProjectBehavior does something similar.

So an idea here would be to mock the GoogleCredentials (particularly the getProjectId method) and in one of the cases, you return a valid Project ID and see if the extension loads or throws an expected GoogleAuthException

Let me know if this makes sense.

Comment on lines +237 to 242
private static Resource customizeResource(Resource resource, String gcpProjectId) {
Resource res =
Resource.create(
Attributes.of(AttributeKey.stringKey(GCP_USER_PROJECT_ID_KEY), gcpProjectId));
return resource.merge(res);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private static Resource customizeResource(Resource resource, String gcpProjectId) {
Resource res =
Resource.create(
Attributes.of(AttributeKey.stringKey(GCP_USER_PROJECT_ID_KEY), gcpProjectId));
return resource.merge(res);
}
// Note that credentials can be passed from `customize` function directly
private static Resource customizeResource(Resource resource, ConfigProperties configProperties, GoogleCredentials credentials) {
String gcpProjectId;
try {
gcpProjectId = ConfigurableOption.GOOGLE_CLOUD_PROJECT.getConfiguredValue(configProperties);
} catch (GoogleAuthException e) {
gcpProjectId = credentials.getProjectId();
if (gcpProjectId == null) {
// this exception will still contain the accurate message.
throw e;
}
}
Resource res = Resource.create(Attributes.of(stringKey(GCP_USER_PROJECT_ID_KEY), gcpProjectId));
return resource.merge(res);
}

void testResolveGoogleProjectIdFromCredentials() {
DefaultConfigProperties configProperties =
DefaultConfigProperties.create(Collections.emptyMap(), Mockito.mock(ComponentLoader.class));

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extra line

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants