-
Notifications
You must be signed in to change notification settings - Fork 168
[gcp-auth-extension]: Try resolving GCP_PROJECT from Google credentials if not provided #2109
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
base: main
Are you sure you want to change the base?
Conversation
|
❌ 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. |
❌ 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. |
1503d82
to
bcafbf9
Compare
018394e
to
be79f44
Compare
Any outstanding blocker about this one? |
...t/java/io/opentelemetry/contrib/gcp/auth/GcpAuthAutoConfigurationCustomizerProviderTest.java
Outdated
Show resolved
Hide resolved
c0929d4
to
46f24dd
Compare
Thanks for the PR @gustavovnicius! My only concern here is to take on the additional
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. |
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.
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 I agree it would be ideal if 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. |
@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. |
New version has been adopted and project id is attempted to be resolved based on credentials. @psx95 |
There was a problem hiding this 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extra line
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 toServiceOptions
, 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