Bug 1793714

Summary: Error deploying ElasticSearch instance regarding vm.max_map_count
Product: OpenShift Container Platform Reporter: Juan Manuel Parrilla Madrid <jparrill>
Component: Node Tuning OperatorAssignee: Jiří Mencák <jmencak>
Status: CLOSED DUPLICATE QA Contact: Mike Fiedler <mifiedle>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.4CC: akamra, aos-bugs, sejug
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-03 13:22:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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