Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[cmd/opampsupervisor] Handle OpAMP connection settings #30237
[cmd/opampsupervisor] Handle OpAMP connection settings #30237
Changes from 15 commits
826f613
99a1bda
3add507
68a633f
45d1533
5e06efa
1f7a776
0a8c0bb
e64019c
e910234
c9570df
2c025cf
a51fbe6
6a10718
c40d622
a9a1e85
eeba0e3
7429102
27d3e0b
a0b4ef1
aab7432
36a16cd
3ba9be9
7d8e3e2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Sorry I had missed this in earlier, and isn't strictly relevant for the PR but I am curious, what does a pointer value add here?
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.
Since the zero-value for
bool
isfalse
but the default value may betrue
, using a pointer instead allows us to use a nil pointer value as a way to represent when the user didn't pass a value in and a default should be used.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.
Should we try to perform this operation in a separate goroutine so that we don't block here in this callback for the entire duration of switching the connections? Let the callback return quickly and initiate the re-establishing of the connection in a separate goroutine.
This would ensure that if the currently received message contains more data and not just connection settings all that data will be processed. With the current approach I am not sure what exactly will happen.
I think callbacks generally should avoid doing long-lasting blocking operations since they than block other callbacks and the entire opamp operation.
I also think the comment here is completely misleading. We should either implement what the comment says (i.e. the caller should do the reconnection) or fix the comment to sat the callback implementation should do the reconnection. @andykellr @evan-bradley Any thoughts on what you would prefer?
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.
Our agent does not currently support
AcceptsOpAMPConnectionSettings
so I have not spent much time with this part of the implementation. Looking at the code, the following things are confusing to me:There are several references to
OnRemoteConfig
(e.g. "See OnRemoteConfig for the behavior."). This was removed a while ago.This sentence doesn't make sense:
We should clearly state who is responsible for establishing a new connection. I could imagine this being fully implemented in the client library and only have
OnOpampConnectionSettings
responsible for validating the fields (e.g. endpoint matching a list of acceptable servers or certificate signed by acceptable authority). If this returns nil, the library would attempt to start a new client with the new settings, send an initial status message, and stop and transition to the new connection on success.If we expect the implementer of the callback to do this, we should describe the process we expect to take place and implement that in tests and the example agent.
https://github.com/open-telemetry/opamp-go/blob/7e92da0f17ef9f2fd0a387dd6b62b451c80f4207/client/internal/receivedprocessor.go#L198-L202
It is not possible to confirm success until the client is started and an initial status message is sent.
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.
onOpampConnectionSettings
is the last part of the message processing in client implementation.Right, the returned value from this callback indicates the reject/accept status of the connection settings. I don't see how we can make this async without changing how the client is expected to handle
OnOpampConnectionSettings
. Also, we don't report the error as described inOnOpampConnectionSettings
open-telemetry/opamp-spec#164.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.
I think this was the original intent. However, I am not sure this is the best approach. It is also not how the example implementation works and I don't see good arguments against how the example is implemented today.
To summarize this is what the example is supposed to do:
The example implementation of steps 4 and 5 is not complete today (e.g not waiting for OnConnect), but can be modified to match what I described.
Thoughts?
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.
I created an issue for this open-telemetry/opamp-go#261
Let's also discuss today in our call.
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.
FYI, open-telemetry/opamp-go#266 removes OnOpampConnectionSettingsAccepted callback.
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.
Updated the implementation to run in a separate goroutine and use OnConnect to determine the connection status.
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.
I wonder if there any value in using some of the
confmap
work to merge these values together instead of needing to update each one explicitly?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.
I am not very familiar with
confmap
work. I will take a look at it and If it helps here I can send a separate PR for it.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.
startOpAMP() initiates but does not wait for successful connection. I think we need to wait for it before we consider the new opamp settings successful. It can be done in a future PR, but would be good to add a TODO here.