feat(helm): allow a separate OTLP endpoint for the mapproxinator container

[razbroc]

Problem

The two containers in this chart's pod do not speak the same OTLP transport, but the chart renders both from a single merged tracing.url.

container	exporter	needs
mapproxy (python)	opentelemetry.exporter.otlp.proto.grpc (src/telemetry/__init__.py:20)	host:4317, no path
mapproxinator (node)	@map-colonies/telemetry -> @opentelemetry/exporter-trace-otlp-proto	host:4318/v1/traces

-proto is the easy trap here: it means protobuf over HTTP, not gRPC (that would be -grpc).

Both templates/mapproxy/mapproxy-configmap.yaml:24 and templates/mapproxinator/mapproxinator-configmap.yaml:27 read the same common.tracing.merged value, so whichever port is configured, one container drops every span - silently, because OTel's diagnostics are off by default.

Observed in a live deployment

With tracing.url = http://infra-otel.infra-services:4317, probing the collector from inside the running mapproxinator container:

:4317/v1/traces  =>  FAILED (HPE_INVALID_CONSTANT)
:4317            =>  FAILED (HPE_INVALID_CONSTANT)
:4318/v1/traces  =>  HTTP 200

HPE_INVALID_CONSTANT is Node's HTTP/1.1 parser hitting the gRPC listener's HTTP/2 response. The image ships only exporter-trace-otlp-proto - there is no gRPC exporter present, so this is not a configuration preference. Meanwhile mapproxy logs [otel-probe] collector REACHABLE at ...:4317 and traces fine.

Upgrading mapproxinator does not resolve it: mapproxinator@1.3.0 moved to @map-colonies/tracing@1.0.0, which still depends on @opentelemetry/exporter-trace-otlp-proto.

Change

An opt-in mapproxinator.tracing.url that takes precedence over the shared endpoint, empty by default:

mapproxinator:
  tracing:
    url: ""   # empty means inherit the shared tracing.url

The configmap now renders .Values.mapproxinator.tracing.url | default $tracing.url.

Chart.yaml is deliberately untouched - release-please owns $.version and $.appVersion via release-please-config.json. As a feat this should land as 2.2.0.

Verification

helm template against this branch:

# no override - unchanged behaviour, both inherit
TELEMETRY_TRACING_URL:      http://infra-otel.infra-services:4317
TELEMETRY_TRACING_ENDPOINT: "http://infra-otel.infra-services:4317"

# mapproxinator.tracing.url set - each container gets its own transport
TELEMETRY_TRACING_URL:      http://infra-otel.infra-services:4318/v1/traces
TELEMETRY_TRACING_ENDPOINT: "http://infra-otel.infra-services:4317"

helm lint passes (only the pre-existing "icon is recommended" info). Rendered output is byte-identical for any consumer that does not set the new key.

Follow-ups (separate repos)

1. helm-charts - bump the mapproxy dependency in raster/charts/serving/Chart.yaml once this releases
2. site-values - bump chartsVersions.serving and set mapproxinator.tracing.url to the collector's HTTP endpoint

Considered and rejected

Adding a matching override for the mapproxy container, or restructuring tracing into grpcUrl/httpUrl. Both widen the chart's public API for a problem that only needs one escape hatch; the shared tracing.url already serves mapproxy correctly.

[razbroc]

Downstream drafts are now open and waiting on this release:

1. this PR - add mapproxinator.tracing.url to the chart
2. feat(raster-serving): upgrade mapproxy chart to 2.2.0 helm-charts-new#154 - bump mapproxy to 2.2.0 in raster-serving (draft)
3. MapColonies/site-values#289 - set the HTTP endpoint for mapproxinator (draft)

Both downstream PRs assume this lands as a feat (mapproxy 2.2.0 under release-please). If it is retitled to fix, the version becomes 2.1.4 and I will update them.