Default chart configuration not fully overridable

[etiennejournet]

Hello,

I understand that you wanted to provide a "base configuration" (config) and an overridable one (standaloneCollector.configOverride or agentCollector.configOverride) and it's very useful. But there is a problem because setting up the Chart will always bring some elements of your default config, even if I have my defaults config in the config file.

So when I use configOverride (for my clients), it's now a three-way merge between your config, my config, and the configOverride. Which makes it quite complicated to understand.

I think there are multiple ways to correct this (if you feel like this needs to be corrected) but I'm not sure which would be the best since I'm unable to fully understand all of your _config.tpl syntaxes.
The easiest solution for me would be to either comment or pass it as multiline string the service, receivers, collectors and exporters, block content into your values.yaml. So that deep merge is still performed up to this depth, but it's easilu overridable. Example:

service: |
    extensions:
      - health_check
    pipelines:
      logs:
        exporters:
          - logging
        processors:
          - memory_limiter
          - batch
        receivers:
          - otlp
      metrics:
        exporters:
          - logging
        processors:
          - memory_limiter
          - batch
        receivers:
          - otlp
          - prometheus
      traces:
        exporters:
          - logging
        processors:
          - memory_limiter
          - batch
        receivers:
          - otlp
          - jaeger
          - zipkin

This doesn't work as-is in otel-collector because of the toYaml (I think) but still get templatized the way I need it to be.

Thanks

[awx-fuyuanchu]

+1 When I set up otel collector as a metrics gateway, it is always set up with some default receivers and exporters which may confuse others and it also could be a security risk as exposes more interfaces than needed. Thanks in advance for your great works.

[js8080]

+1 I just spent the last few hours struggling with this. I am not super experienced with Helm but I find this chart is unlike many others I have seen in its behavior.

[TylerHelmuth]

@dmitryax Is this something to address after/during the refactor referenced in #91

[TylerHelmuth]

@dmitryax Gonna take a look at this now

[dmitryax]

@TylerHelmuth yes, this one will be resolved after the chart configuration interface restructuring https://github.com/open-telemetry/opentelemetry-helm-charts/issues/91

[TylerHelmuth]

@TylerHelmuth yes, this one will be resolved after the chart configuration interface restructuring #91

Ok I will hold off then.

[TylerHelmuth]

The latest chart now allows completely overriding the default configuration. Let me know if this issues needs to be reopened.