Is there a way to provide the config in Instrumentation and OpenTelemetryCollector in the form of a configmap?
Hello,
I cannot find any way how to pass the config as a configmap rather than the inline config
config: |
receivers:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
load:
memory:
...
Applies for both Instrumentation and OpenTelemetryCollector.
.. or am I just missing something?
Thx
Could you define it as a volume and then override --config with args?
I'm also interested in if offering more ways to pass config has been considered. For one use case, it would be nice to be able to patch my config to add/change/remove sections without having to rewrite the whole string (eg, when applying multiple configs over each other)
The operator right now does not support passing the config as a config map. The design goal was to have a single CR that defines the whole stack/deployment.
Being able to patch the collector config is a valid use case.
@petrmac what is your use-case for the configmap?
@petrmac could you please elaborate what would you like to configure in the Instrumentation CR? The instrumentation CR does not have any string config like the collector CR (.spec.config).
One use case could be a centralized spot for configs when running multiple collectors. It also enables patching, at least with local yaml config files. In general it's a common approach I've seen in operators that manage configured components like this. However I am also not sure what the application is for Instrumentation CRs
Working on a poc for this /assign
Opened a PR at https://github.com/open-telemetry/opentelemetry-operator/pull/1240, ptal
@damemi we now have the ability to mount multiple configmaps (https://github.com/open-telemetry/opentelemetry-operator/pull/1989/files). you should be able to mount a config and supply them as args. Please let me know if that doesn't resolve this use case.
If someone wants this for Instrumentation please open a separate issue.
I think this is still a problem that we should attempt to simplify in the next CRD version. CC @TylerHelmuth and @pavolloffay who I discussed this w/ at KubeCon