Config workflow for client-side (RUM) SDKs

[scheler]

Since the OpAmp spec includes support for configuration of Otel SDKs as well, this issue concerns applying the same protocol/workflow to client-side (RUM) SDKs (mobile apps and browser apps), which are typically resource constrained and so cannot have a constant WebSocket connection or even do polling.

Instant config updates is not a critical requirement for these SDKs, so I am wondering if there are alternate ways to indicate a configuration offer to the SDK than what's outlined in the OpAmp spec. For example, if there was a way to indicate the config offer in an OTLP response (sent conditionally when the OTLP client expresses interest via an HTTP header), then the SDK could initiate the WebSocket connection to OpAmp server and keep it until the completion of config update. Thoughts/comments?

[tigrannajaryan]

There is an open issue to support OpAMP over plain HTTP: #50

I think this should work for client-side SDKs.

[scheler]

That would still require periodic polling on a separate channel/connection, which is prohibitive for client-side environments. So it is not about http vs websocket, but about having two separate channels of communication all the time, one for sending telemetry and another for receiving config updates. It would be great if the second channel comes into play only on demand, rather being there all the time.

[tigrannajaryan]

It is probably possible to modify the OTLP response to hint that OpAMP polling is necessary but it will only work if there is no intermediary Collector, since the Collector never propagates the OTLP responses back.

[scheler]

That's a good point. It will be a limitation for cases when collector is required and the SDKs need to use the original method.

Also, it's not clear to me if an intermediary Collector is required for Client-side SDKs as they are running on public Internet.