Enable adding user-defined environment variables to collector/query

[kacper-jackiewicz]

During the testing I found out that there is no possibility to update the environment variable part of deployment.
From what I am seeing in the operator code that part of deployment spec is constant, in the meaning of hard coded list of variables which take changeable values from jaeger cr spec.

My questions are:

• Am I missing something? Is there any possible way to add additional env variable for example go specific variables like GO_MAX_PROC?
• Is this done deliberately or will it be accounted for in the near future? If it is on purpose what is the exact reason for disabling env variables changes.

[pavolloffay]

It's a design decision. The operator does not allow users to change created objects. All changes are reverted.

All configuration is only available via jaeger CR.

[kacper-jackiewicz]

Is there a possibility to add env variables through Jeager CR?

[pavolloffay]

I don't think there is. Let's take this by use cases what properties would you like make configurable?

[kacper-jackiewicz]

First thing would be to have ability to add new environment variables per component e.g.

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger
spec:
  strategy: production
  storage:
  ...
  collector:
    replicas: 2
    options:
    ...
    env:
    - name: GOMAXPROCS:
       value: '5'
   
   and additional variables needed

[pavolloffay]

That would allow users to arbitrary change jaeger configuration. Is the goal to configure only GOMAXPROCS? The operator should set this variable automatically if it is needed.

[kacper-jackiewicz]

From my side for now it is only GOMAXPROCS. In case that this controlled by operator I will not need to change that. Thanks for quick response.

[pavolloffay]

GOMAXPROCS sets the maximum number of CPUs that can be executing simultaneously and returns the previous setting. If n < 1, it does not change the current setting. The number of logical CPUs on the local machine can be queried with NumCPU. This call will go away when the scheduler improves.

Do you have any recommendations on the value? Should we set it to resource requests?

[kacper-jackiewicz]

In our deployments, GOMAXPROCS value was always matching the resource limits, but in that case request limits/requests need to be fixed

[pavolloffay]

I am wondering whether this library https://github.com/uber-go/automaxprocs would offer a better solution rather than setting it explicitly on the manifest.

[kacper-jackiewicz]

It seems like it would be more flexible solution.

[jpkrohling]

I'm closing this, as it was added to Jaeger itself. It should be available whenever the next version is released, probably 1.13.