Implement opamp extension configuration reading and validation

[tigrannajaryan]

No description provided.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[srikanthccv]

@tigrannajaryan, since the open-telemetry/opentelemetry-collector#6599 is completed, I think we can use the service.instance.id as a replacement for instance_uid. So the config for opamp extension would look something like.

type Config struct {
    Endpoint string `mapstructure:"endpoint"`
    confighttp.HTTPClientSettings `mapstructure:",squash"`
}

[tigrannajaryan]

HTTPClientSettings typically assumes you use ToClient() to get an http.Client to work with. This won't work with OpAMP which implements its own client connection and there is no way to pass an http.Client to use: https://pkg.go.dev/github.com/open-telemetry/opamp-go@v0.7.0/client

If you can't use ToClient() you have to re-implement everything HTTPClientSettings does, which I am not sure is a good idea.

Possible options are:

• Change NewHTTP to accept http.Client to use. That would limit OpAMP extension to OpAMP/HTTP transport only, since WebSocket doesn't use http.Client at all. This is very undesirable, I want OpAMP extension to support OpAMP/WebSocket transport and use that for local interaction between Supervisor and Collector.
• Don't use HTTPClientSettings directly. Instead borrow just the fields that we can support with existing OpAMP clients (Endpoint, Headers, TLSConfig, Compression).

[srikanthccv]

I was thinking we could use the HTTPClientSettings and decide whether to use the ToClient based on the provided scheme. Use the Dialer if the URL scheme is ws/wss. I think borrowing the relevant fields is a good idea. Can we add WithClient/WithDailer opamp client that allows users to provide custom http.Client/websocket.Dialer? What do you think?

[tigrannajaryan]

Can we add WithClient/WithDailer opamp client that allows users to provide custom http.Client/websocket.Dialer? What do you think?

I think it should be possible.

[srikanthccv]

I wonder if there was a reason behind passing settings at the time of Start instead of creating a new client with ClientSettings. Functionally I don't see much of a difference; having it already set up with given settings before the Start call makes it easier to customize sender/dailer. Either way, I can pick some of these issues and start working, but I guess there should be an extension skeleton first.

[evan-bradley]

I think the basic requirements of this issue have been met, providing custom transport clients to the OpAMP client library will need to be tackled separately in opamp-go.