Extract OTEL parsing to configMap to allow consistent handling of env

[DiamondJoseph]

This handling does not require that string parsing is done on the extraEnvVars, and so resolves the need for them to be a string re: #582

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.27%. Comparing base (fa20204) to head (3771e51).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #719   +/-   ##
=======================================
  Coverage   92.27%   92.27%           
=======================================
  Files          35       35           
  Lines        1800     1800           
=======================================
  Hits         1661     1661           
  Misses        139      139           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[callumforrester]

I suggest @keithralphs take a look too.

I'm happy with this change. It does, however, bring to mind why I initially suggested aligning the OTEL configuration with the rest of the BlueAPI configuration (loaded from YAML, etc.). While it was considered too complex due to the internals of the OTEL library, the fact that we've had to put special handling in here makes me wonder if it's worth revisiting this approach.

Maybe make an issue?

[callumforrester]

Is this doing anything?

[DiamondJoseph]

Just me being a hater on how clunky the key name is.

[callumforrester]

Oh I agree with that, but is that key actually used anywhere?

[DiamondJoseph]

{{ if .Values.tracing.otlp.enabled | default false }}

It is the condition that enables filling the ConfigMap.

[keithralphs]

need to resolve the port and protocol spec ot it won't work

[DiamondJoseph]

@keithralphs fixed both, and have tested that the config map made locally is formatted correctly.