Support a configurable default agent configuration to be implemented by OpAMP supervisor

[pabloem]

Component(s)

cmd/opampsupervisor

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

I am implementing the OpAMP protocol across our fleet, and I find that I want agents to implement a default configuration if the supervisor is unable to reach the OpAMP server.

• Why?

We want most hosts to have a simple default config: Receive OTLP logs in a given port and forward them to our log-processing infrastructure. I want to be sure that this configuration will be enabled even in restricted environments (e.g. environments managing sensitive data - thus blocked by firewalls, etc).

Happy to discuss further.

Describe the solution you'd like

I propose a new parameter agent.base_config in the supervisor that points to a base configuration file that is enabled if we can't get another one. Basic implementation is here:

#32192

Another feature of the PR above is that it avoids overwriting the effective.yaml config to be sure we don't overwrite a config that might have worked in the past.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• cmd/opampsupervisor: @evan-bradley @atoulme @tigrannajaryan

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[tigrannajaryan]

I propose a new parameter agent.base_config in the supervisor that points to a base configuration file that is enabled if we can't get another one.

This seems very similar to collector.config_file setting defined here https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/opampsupervisor/specification#supervisor-configuration

Would collector.config_file work for you?

[pabloem]

yes looks like that should work.

[evan-bradley]

Just to clarify: do we expect collector.config_file will be used even if the Supervisor cannot connect to the OpAMP server? The description says it will be merged with the remote config.

I would expect that a "fallback" config that is used in the case the server is unreachable would be different from a config file that is layered on top of the remote config. @pabloem how do you want this to work in your use case?

[tigrannajaryan]

Just to clarify: do we expect collector.config_file will be used even if the Supervisor cannot connect to the OpAMP server? The description says it will be merged with the remote config.

Perhaps we make this the "fallback" config? Does it need to be different?

[evan-bradley]

I think the two use cases are different. My understanding of the intent of the current option is based on the description:

Path to optional local Collector config file to be merged with the config provided by the OpAMP server.

Based on this, my expectation is that this file would supplement/overwrite config provided by the server. I would expect the "fallback" and "extra config" cases to be different. For example in the fallback scenario I may have a specific backend I want to send to.

I would be fine just making this a fallback option and only providing a file that is merged with the config from the server if we have user requests for it. I think inlining config from local files inside the server config (e.g. ${file:extra_config.yaml}) should be sufficient for now.

[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.

Pinging code owners:

• cmd/opampsupervisor: @evan-bradley @atoulme @tigrannajaryan

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.