You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When connecting to an OpAMP management server using ws or http protocols, server.tls.insecure needs to be configured as true. This should not be necessary since it should be implied with those protocols that it is insecure.
Steps to Reproduce
Run the supervisor configured to connect to an OpAMP management server using ws or http. My server config is below:
I expected the supervisor to connect successfully without error.
Actual Result
The supervisor fails with this message and enters a retry loop that continually fails with the same error.
2024-09-18T13:50:48.573-0400 ERROR supervisor/supervisor.go:411 Failed to connect to the server {"error": "tls: first record does not look like a TLS handshake"}
Only once the supervisor config is updated with server.tls.insecure: true does the supervisor manage to successfully connect to the server.
2024-09-18T13:50:48.573-0400 ERROR supervisor/supervisor.go:411 Failed to connect to the server {"error": "tls: first record does not look like a TLS handshake"}
2024-09-18T13:50:48.573-0400 ERROR supervisor/logger.go:26 Connection failed (tls: first record does not look like a TLS handshake), will retry.
2024-09-18T13:50:48.978-0400 ERROR supervisor/supervisor.go:411 Failed to connect to the server {"error": "tls: first record does not look like a TLS handshake"}
2024-09-18T13:50:48.979-0400 ERROR supervisor/logger.go:26 Connection failed (tls: first record does not look like a TLS handshake), will retry.
This continues until I stop the process.
Additional context
I believe the relevant code is here. LoadTLSConfig() is always called when creating the OpAMP client and it does not consider the protocol being used. I have a fix in progress that will skip calling LoadTLSConfig() if we're using ws or http.
The text was updated successfully, but these errors were encountered:
)
**Description:** <Describe what has changed.>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
Fixes an issue where TLS would be used despite the opamp server using
`ws` or `http` protocols.
Before a TLS config would always get created, causing the connection to
always use TLS settings. This change first checks which protocol we're
using before creating a TLS config.
**Link to tracking Issue:** <Issue number if applicable> Fixesopen-telemetry#35283
**Testing:** <Describe what testing was performed and which tests were
added.>
Removed `tls.insecure_skip_verify: true` from e2e test configs which
were using `ws` protocol since they are no longer needed.
**Documentation:** <Describe the documentation added.>
Component(s)
cmd/opampsupervisor
What happened?
Description
When connecting to an OpAMP management server using
ws
orhttp
protocols,server.tls.insecure
needs to be configured astrue
. This should not be necessary since it should be implied with those protocols that it is insecure.Steps to Reproduce
Run the supervisor configured to connect to an OpAMP management server using
ws
orhttp
. My server config is below:Expected Result
I expected the supervisor to connect successfully without error.
Actual Result
The supervisor fails with this message and enters a retry loop that continually fails with the same error.
Only once the supervisor config is updated with
server.tls.insecure: true
does the supervisor manage to successfully connect to the server.Collector version
main (present in current commit 292f291)
Environment information
Environment
OS: macOS Sequoia 15.0
Compiler: go 1.23
OpenTelemetry Collector configuration
Log output
Additional context
I believe the relevant code is here.
LoadTLSConfig()
is always called when creating the OpAMP client and it does not consider the protocol being used. I have a fix in progress that will skip callingLoadTLSConfig()
if we're usingws
orhttp
.The text was updated successfully, but these errors were encountered: