-
Notifications
You must be signed in to change notification settings - Fork 134
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
Add GCP authentication extension #1631
Conversation
d30c460
to
a343830
Compare
a343830
to
e140374
Compare
The updated documentation makes it clear that the extension is not explicitly for the Java Agent, but can be used without it as well.
// Setup proxy host(s) | ||
System.setProperty("http.proxyHost", "localhost"); | ||
System.setProperty("http.proxyPort", MOCK_GCP_OAUTH2_PORT + ""); | ||
System.setProperty("https.proxyHost", "localhost"); | ||
System.setProperty("https.proxyPort", MOCK_GCP_OAUTH2_PORT + ""); | ||
System.setProperty("http.nonProxyHost", "localhost"); | ||
System.setProperty("https.nonProxyHost", "localhost"); | ||
|
||
// Disable SSL validation for integration test | ||
// The OAuth2 token validation requires SSL validation | ||
disableSSLValidation(); |
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.
A concern here is that since the setup()
code runs after the agent is loaded, in case the agent establishes some HTTP connections before setup()
is able to run, those connections will not respect these settings.
Right now, it seems like the agent makes HTTP connections only at the time of export and the test has added delay of 2 seconds for the export to happen, which is why the test currently works.
The concern is that if there are changes in the agent implementation, where the agent establishes HTTP connections when it is loaded and the exporters are configured to use such pre-established connections, this test might start failing as the SSL configuration done here might not be respected.
Basically, this test is kind of depending on un-documented behavior of the Java agent.
Are these concerns valid ? If so, is there a better way to write this test ?
P.S - This is not a blocker to the PR, since we have reliable unit testing.
@trask @jsuereth
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 use self-signed cert in java-instrumentation repo for testing, and add it to trusted certs via JVM command line (https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/4ea2005bc478d14abd241b8be60226d42a6f601e/conventions/src/main/kotlin/otel.java-conventions.gradle.kts#L356)
i'm not sure if this is an option here?
in any case this test doesn't bother me as-is, I'm ok merging it, just let me know, thanks!
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 @trask!
I will explore this option to enhance the test in a separate PR, but this is not a blocker for now.
Feel free to merge this.
Description:
Adds a Javaagent extension that provides Google Cloud authentication support for built-in OTLP exporters.
Testing:
Documentation:
README.md includes documentation on how to use this extension.
Outstanding items: