Should the CR enable set parameters to be defined, and if so, how?

[objectiser]

Based on recent discussions, it was agreed that the Jaeger components will have default "opentelemetry" configurations, which can be overridden by a user supplied configuration, and/or modified using a --set parameter.

For the Jaeger V2 CR, it will be possible to either provide no config, so use the component's default, or explicitly provide the complete OpenTelemetry Collector config - so override the component's default configuration.

However it is not clear whether to use the --set parameter capability, to adjust specific values in the default or overridden configuration, and if so, how it should be specified in the Jaeger V2 CR.

A usecase for allowing the --set to be used is the agent default configuration - by default it would have receivers for otel and jaeger protocols, and a OTLP exporter to send trace data to a central collector. However, the address of that central collector would not be part of the default configuration. So either we always require the user to specify the complete OTC config, or we support a mechanism that enables just the OTLP exporter's endpoint to be overridden.

The problem is that there is no way to verify these set parameters from the CR - although the same is true with the V1 CLI parameters.

If they are going to be supported, we need to determine how they should be represented in the CR. Potentially it could have the same structure as the current components, which have options and config as the sub-nodes under agent, collector, etc. With V1 CRD, the options would be the CLI parameters, and with V2 they would be --set parameters.