Skip to content
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

Agent vs Client is a bit confusing #114

Closed
tigrannajaryan opened this issue Jul 26, 2022 · 3 comments
Closed

Agent vs Client is a bit confusing #114

tigrannajaryan opened this issue Jul 26, 2022 · 3 comments
Labels
required-for-stable Required to be resolved before 1.0

Comments

@tigrannajaryan
Copy link
Member

The spec currently uses the term Agent mostly (although Client can be seen in the Communication Model). The Go implementation on the other hand uses the term Client.

This is a bit confusing.

Should we mostly use the term OpAMP Client and only where relevant talk about the Agent?

This is especially more important now that Supervisor seems to be a likely option to implement OpAMP for Otel Collector. It makes things even more confusing. Unclear whether OpAMP Agent is (Supervisor+Collector) or just Supervisor.

@andykellr
Copy link
Contributor

In the 8/9 agent management meeting we agreed that Client is the preferred term.

@PeterF778
Copy link
Contributor

One of the arguments for "Client" is that it well describes the role this endpoint plays in the protocol, while "Agent" suggests functionality, which, while important, is not really defined by the protocol. Furthermore, Agent might become even more confusing if we will have Tracer/SDK implementation(s) of the client side of the protocol in the future.

@tigrannajaryan
Copy link
Member Author

@andykellr I agree. We should probably create a PR that tries to rename Agent->Client where relevant (while still keeping Agent where it actually refers to the Agent). We should probably also rename the Protobuf messages (e.g. AgentToServer becomes ClientToServer, etc).

Do you think you will be able to submit a PR like that? If not then I can try to do it myself in a couple weeks (busy with something else right now).

We should do a draft PR first to see what it looks like. I am not entirely sure it will work nicely, but we should try.

tigrannajaryan added a commit to tigrannajaryan/opamp-spec that referenced this issue Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
required-for-stable Required to be resolved before 1.0
Projects
None yet
Development

No branches or pull requests

3 participants