Description
Component(s)
cmd/opampsupervisor
What happened?
Description
The supervisor will not start the collector if it is given a nop config to run it with. However, there is also functionality in place to report an error if the collector doesn't start up after it receives a new config. This functionality does not consider if the supervisor was given a nop config to run the collector with, so it reports an error to the OpAmp server in this case.
Steps to Reproduce
Configure & run the supervisor to connect to an OpAmp server. From the server, send down a working, non-nop config. Verify the supervisor and collector are healthy and running this config. Now send down a nop config:
receivers:
nop:
exporters:
nop:
service:
pipelines:
metrics:
receivers: [nop]
exporters: [nop]Expected Result
The supervisor does not run the collector with the received configuration because it is a nop config. No errors are reported to the OpAmp server though because this is a performance optimization to not run the collector. There is no effective difference when the collector is actually running a nop config vs when it doesn't.
Actual Result
The supervisor does not run the collector with the received configuration because it is a nop config. The supervisor does however report a RemoteConfigStatuses_FAILED error to the OpAmp server. This occurs because this logic that determines whether or not the remote config was successfully applied does not consider if the supervisor intentionally opted to not start the collector because it received a remote config.
Collector version
main
Environment information
No response
OpenTelemetry Collector configuration
No response
Log output
No response
Additional context
I can implement a correction for this behavior. I think simplest is to check whether or not the collector's config is a nop before reporting an error when the timeout occurs. This sort of check is done several times elsewhere in the code.