Bug 1793714 - Error deploying ElasticSearch instance regarding vm.max_map_count
Summary: Error deploying ElasticSearch instance regarding vm.max_map_count
Keywords:
Status: CLOSED DUPLICATE of bug 1791916
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node Tuning Operator
Version: 4.4
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 4.4.0
Assignee: Jiří Mencák
QA Contact: Mike Fiedler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-21 22:16 UTC by Juan Manuel Parrilla Madrid
Modified: 2023-09-14 05:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-03 13:22:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-logging-operator issues 336 0 None closed ElasticSearch or Cluster-Logging Operator should extend the vm.max_map_count 2020-03-18 14:36:56 UTC
Github openshift cluster-logging-operator pull 337 0 None closed [RFE] [DOC] Added reference about increase vm.max_map_count using Tuned operator 2020-03-18 14:36:53 UTC

Description Juan Manuel Parrilla Madrid 2020-01-21 22:16:21 UTC
Description of problem:

Once deployed ElasticSearch Operator and then Cluster-Logging Operator (Both Downstream and 4.4) on Openshift 4.3 we check that the deploy ment of ElasticSearch cluster does not finish because of an error regarding the size of vm.max_map_count kernel parameter.

Version-Release number of selected component (if applicable):

- OCP 4.3
- OCS v4.4.0 (CephFS for ElasticSearch cluster)
- Cluster-Logging Operator v4.4.0
- ElasticSearch Operator v4.4.0

How reproducible:

The entire process of deployment is described here:

https://docs.google.com/document/d/1GScQEti8X7gK1lf-4QPn-W9FRjx_GzEh9SUOvL43nPM/edit?usp=sharing

Even including the workaround

Steps to Reproduce:
1. Deploy OCP 4.3
2. Deploy OCS 4.4 and create the appropiate StorageClasses
3. Deploy ElasticSearch Operator (v4.4.0) from custom OperatorGroup (Any internal one)
4. Create the appropiate Namespaces (openshift-logging
5. Deploy Cluster-Logging Operator (v4.4.0) from custom OperatorGroup (Any internal one)
6. Deploy an instance of Cluster-Logging operator on the proper namespace
7. Change the images from internal registry to the Engineering registry

Actual results:

This is the error that appears on the ELS log:

Consider setting -Djdk.tls.rejectClientInitiatedRenegotiation=true to prevent DoS attacks through client side initiated TLS renegotiation.
Consider setting -Djdk.tls.rejectClientInitiatedRenegotiation=true to prevent DoS attacks through client side initiated TLS renegotiation.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]


Expected results:

ELS cluster instance up and running


Additional info:

- Discussion here: https://github.com/openshift/cluster-logging-operator/pull/337
- Previous issue here: https://github.com/openshift/cluster-logging-operator/issues/336

Comment 1 Anping Li 2020-01-21 22:30:53 UTC
Could you check the pod namespace openshift-cluster-node-tuning-operator? I guess some tune pods are not running. 

oc get pod -n openshift-cluster-node-tuning-operator
you can fix it by 'oc delete ds tuned '

Comment 3 Jiří Mencák 2020-01-22 15:38:08 UTC
Thank you for the report.  Could you please run 
oc get clusterversion
oc get pod -n openshift-cluster-node-tuning-operator

Please find the node on which the Elastic search pod runs.  Then, find the tuned pod that runs on the same node as the failing Elastic search pod.

oc logs <Tuned pod running on the same node as the failing Elasticsearch>

Comment 4 Jiří Mencák 2020-03-03 13:22:33 UTC
Closing a BZ on the grounds of no additional information provided.  Very likely a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1791916

Please re-open if the solution does not work for you.

*** This bug has been marked as a duplicate of bug 1791916 ***

Comment 5 Red Hat Bugzilla 2023-09-14 05:50:29 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.