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

[Proposal] OpAMP client implementation #1463

Open
LikeTheSalad opened this issue Sep 19, 2024 · 3 comments
Open

[Proposal] OpAMP client implementation #1463

LikeTheSalad opened this issue Sep 19, 2024 · 3 comments

Comments

@LikeTheSalad
Copy link
Contributor

Component(s)

No response

Is your feature request related to a problem? Please describe.

We currently don't have a Java OpAMP client implementation available in an OTel repo.

Describe the solution you'd like

A client implementation that would (at least) allow for:

  • Remote configuration.
  • Status reporting.

This PoC can be used as a reference for what this implementation would look like.

Ideally, those features should be available to use for any use case from an external codebase, although it'd be nice to use that functionality to build specific Java SDK remote config use cases on top as a way to ensure that the generic APIs are well suited for a real-world use case.

Once the generic APIs reach a stable status, they can be moved into their own OpAMP repo, where they can live alongside a server implementation, following a similar pattern as the OpAMP Go one.

Describe alternatives you've considered

No response

Additional context

No response

@tigrannajaryan
Copy link
Member

  • Remote configuration.

Do we expect to make the entire list of SDK options remotely configurable or a select subset that is deemed safe?

OpAMP spec's security section has recommendations on this topic. It would be useful to clarify SDK maintainers thinking in this area.

@LikeTheSalad
Copy link
Contributor Author

Do we expect to make the entire list of SDK options remotely configurable or a select subset that is deemed safe?

My understanding from previous Java SIG meetings is that the config files will describe signal processors (along with their exporters), which makes me think that a lot of the SDK options would be remotely configurable. Though I don't have the specific details on what will be configurable in the SDK, I think @jack-berg is better suited to provide more info on them.

@LikeTheSalad
Copy link
Contributor Author

Btw @tigrannajaryan - I cannot add reviewers to PRs in this repo, though just wanted to let you know about this one which is where the "main API" is added, in case you're interested to take a look. I tried to make it similar to the one in the Go impl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants