Allow configurable JVM options

[sebgl]

For now, we only hardcode "-Xms%dM -Xmx%dM -Djava.security.properties=%s", heapSize, heapSize, version.SecurityPropsFile

[nithril]

Is there already a release date associated to this issue?

Thank you!

[sebgl]

@nithril can you share what you would like to achieve with JVM options override? That would help us prioritize this.

[nithril]

To configure the GC options (G1)

[sebgl]

#943 propagates user-defined environment variables from the ES spec's podTemplate to the pod.

We do override the ES_JAVA_OPTS with our own though, so this does not solve the issue.

We should probably should pass those settings through a file (jvm.option) - relates #931.

This way, the user-provided ES_JAVA_OPTS should be used on top of our defaults in jvm.options. We should first check that providing both jvm.options and ES_JAVA_OPTS does work in a way that suits us (giving priority to the environment variable but still considering what's in jvm.options).

[nrobert13]

I see an inconsistent propagation of the env var ES_JAVA_OPTS:
I have the following in my CR:

    podTemplate:
      spec:
        containers:
        - name: elasticsearch
          env:
          - name: ES_JAVA_OPTS
            value: "-Xms512M -Xmx768M"
          resources:
            limits:
              memory: 1Gi
              cpu: 500m

and when I check the pod I get:

    env:
    - name: ES_JAVA_OPTS
      value: -Xms512M -Xmx512M -Djava.security.properties=/usr/share/elasticsearch/config/managed/security.properties
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi

1. Not sure where the Xmx512 is coming from, is neither the one requested by me (768M) nor the default (1024M).
2. also noticed that updating the ES_JAVA_OPTS and reapplying the manifest will not re-conciliate...

[sebgl]

Hi @nrobert13, #956 fixes that behaviour. Alpha release 0.8 does not allow you to set this yet. This is fixed in master, and will be available in the next release.
We'll write proper documentation as part of #1031.

The goal here is to simply propagate the ES_JAVA_OPTS you define into the Elasticsearch pod, as you would expect.

[nrobert13]

Hi @sebgl , thanks for the reply. Yeah, I'm using 0.8.0. Does the fix address the #2 point as well, to trigger reconciliation on podTemplate changes? It doesn't seem to reconcile on env or resources changes applied to the elasticsearch CR.

[sebgl]

I double-checked on the latest master, the operator does correctly reconcile on:

• ES_JAVA_OPTS changes
• resource changes

We do not cover the entire spectrum of changes people can do in the podTemplate though, I opened #1046 to fix the remaining bits.

[sebgl]

Closing this issue now, this is implemented in master, will be implemented and documented in release 0.9.