Component(s)

collector

Is your feature request related to a problem? Please describe.

OpenTelemetry operator accepts custom configs in the spec to create all the resources on its behalf. Jaeger V2 follows the setting up of parameters using config files rather than passing them through the CLI flags in the command. The OTEL operator created resources like pods, deployments, service accounts, and services when custom configs were passed to create an OTEL instance for Jaeger V2. However, to interact with the UI, a forwarding port was required which is not something we should follow in a production environment.

Describe the solution you'd like

To cater this, a new method is being implemented that will create a new service explicitly for extensions. The newly created service will be consumed by the ingress to give users a way to directly interact with the ui (in Jaeger's case it's jaeger_query).

Since, the Operator has a parameter ingress which creates an Ingress according the specification set by the users themselves. Is it a good a idea to use the existing functionality?

Describe alternatives you've considered

Other way of creating ingress could be similar to the way extension service is being implemented. In this, we can create a method e.g., ExtensionIngress which will only be responsible for creating ingress for extensions. This will also leave less room for errors as it will automate the entire flow and users won't have to worry about them at all.

Additional context

Jaeger V2: jaegertracing/jaeger-operator#2717
Extension Service: #3403