API configured for traces even with tracing disabled

Notice that https://github.com/observatorium/observatorium/blob/main/configuration/examples/dev/manifests/api-deployment.yaml#L43 has

        - --traces.write.endpoint=observatorium-xyz-otel-collector:4317
        - --grpc.listen=0.0.0.0:8090

Of the three examples, only local has tracing enabled, yet all three examples supply now the flags to the API to forward traces. (Since https://github.com/observatorium/observatorium/pull/461 ). Tracing .enabled does correctly control the deployment of tracing components.

I am looking into the fix but Jsonnet debugging is new to me. I have the syntax figured out, but Jsonnet's lazy declarative semantics make it tricky to figure out why part of the Jsonnet respects tracing .enabled and another part doesn't.

cc @pavolloffay

I wonder if .enabled is kind of an anti-pattern. We don't use this field to control the enabling of logging or metrics, only the existence of the configuration is enough. Perhaps the solution is rather to eliminate enabled entirely?

@squat You have a good point. Perhaps this is why the previous version enabled it.

Is your issue the boolean enabled and you'd prefer the user control this with an empty write endpoint? I am happy to re-do this PR in that style.

It troubled me that we use enabled to turn off deployment of the back-end, but configure the API to forward traces. If the user has chosen to deploy without traces we shouldn't offer the APIs. It gives confusing gateway errors and increases the attack surface.

Right. I wonder if this makes sense to do as @squat mention - treat no endpoint config as enabled=false