[RFE] [DOC] Added reference about increase vm.max_map_count using Tuned operator

[jparrill]

In order to clarify the procedure to use and consume the ElasticSearch Operator and deploy an instance of ElasticSearch, I've added a reference about how to increase vm.max_map_count using the Cluster Node Tuning Operator on the doc.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jparrill
To complete the pull request process, please assign syedriko
You can assign the PR to them by writing /assign @syedriko in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ewolinetz]

the node tuning operator already does this for nodes that have the pod with that label tuned.openshift.io/elasticsearch which the elasticsearch operator applies already.

and with OCP 4 you will be unable to make this change on nodes manually as it will taint them - preventing pods from being scheduled on them.

There are no additional steps for users to take at this time.

[jparrill]

IMHO as a customer, would like to have some kind of reference that reflects what we should do to patch this kernel parameter, It would be nice to have something that points them in the right direction.

Just my opinion

[jcantrill]

IMHO as a customer, would like to have some kind of reference that reflects what we should do to patch this kernel parameter, It would be nice to have something that points them in the right direction.

While true, can a customer actually do this without the node tuning operator? Note, this operator is not intended (yet atleast) to be a general purpose EO so its unlikely this would be deployed outside the context of where the node tuning operator also lives.

[jparrill]

IMHO as a customer, would like to have some kind of reference that reflects what we should do to patch this kernel parameter, It would be nice to have something that points them in the right direction.

While true, can a customer actually do this without the node tuning operator? Note, this operator is not intended (yet atleast) to be a general purpose EO so its unlikely this would be deployed outside the context of where the node tuning operator also lives.

Yep, could be done by a MachineConfig patch, something like:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-sysctl-elastic
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          # vm.max_map_count=262144
          source: data:text/plain;charset=utf-8;base64,dm0ubWF4X21hcF9jb3VudD0yNjIxNDQ=
        filesystem: root
        mode: 0644
        path: /etc/sysctl.d/99-elasticsearch.conf

What I want to say, is just to guide the user in the right way just adding a small reference that what is necessary to be done before they do something wrong ://.

If this is explained in other place maybe I skip it in the ELS Operator doc or something like that, it's fine also :).

[eparis]

I think I'm hearing @jparrill say that his ES nodes did not have this setting? And I'm hearing @ewolinetz say the nodes should be getting this setting automatically.

So if they aren't getting the setting we have a bug?

[jparrill]

@eparis Exactly, on my tests, the ELS cluster doesn't goes up because of this problem and on ELS logs shows exactly that this parameter is not correctly set (was by default).

[eparis]

can you file a BZ, with versions and reproducer. This MC shouldn't be required as I'm understanding things.

[jparrill]

Here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1793714