Description of problem: The following logging section in the Ansible Hosts file should create a NFS (I know, I know.... not recommended) logging PV that gets mounted into the elasticsearch pod. However the elasticsearch pod ends up with 'EmptyDir' storage instead. There is no PVC created either. The PV however is created successfully. Verified on 3.7.14 and 3.7.23. /etc/ansible/hosts: [...] # Enable cluster logging openshift_logging_install_logging=True openshift_logging_storage_kind=nfs openshift_logging_storage_access_modes=['ReadWriteOnce'] openshift_logging_storage_nfs_directory=/srv/nfs openshift_logging_storage_nfs_options='*(rw,root_squash)' openshift_logging_storage_volume_name=logging-es openshift_logging_storage_volume_size=10Gi openshift_logging_storage_labels={'storage': 'logging'} openshift_logging_es_cluster_size=1 openshift_logging_es_memory_limit=2Gi openshift_logging_es_nodeselector={"env":"infra"} openshift_logging_kibana_nodeselector={"env":"infra"} openshift_logging_curator_nodeselector={"env":"infra"} [...] $ oc get pv [...] logging-volume 10Gi RWO Retain Available 6d [...] $ oc get pv -n logging empty $ oc describe pod logging-es-data-master-97nowzyw-1-9qpj7 [.....] Volumes: proxy-tls: Type: Secret (a volume populated by a Secret) SecretName: prometheus-tls Optional: false elasticsearch: Type: Secret (a volume populated by a Secret) SecretName: logging-elasticsearch Optional: false elasticsearch-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: logging-elasticsearch Optional: false elasticsearch-storage: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: aggregated-logging-elasticsearch-token-h2j4x: Type: Secret (a volume populated by a Secret) SecretName: aggregated-logging-elasticsearch-token-h2j4x Optional: false Version-Release number of the following components: How reproducible: Always Steps to Reproduce: 1. Add Logging section to Ansible Hosts file 2. Install OCP 3. PV gets created 4. PVC does not get created 3. EmptyDir volume definition in Deployment Config
after different tests, i found a workaround. This set of variables works with 3.7.23: openshift_logging_install_logging=True openshift_hosted_logging_deploy=True openshift_hosted_logging_storage_kind=nfs openshift_hosted_logging_storage_nfs_directory=/srv/nfs openshift_hosted_logging_storage_nfs_options='*(rw,root_squash)' openshift_hosted_logging_storage_volume_size=10Gi openshift_hosted_logging_storage_labels={'storage': 'logging'} openshift_logging_es_pvc_storage_class_name='' openshift_hosted_logging_storage_access_modes=['ReadWriteOnce'] openshift_hosted_logging_storage_volume_name=logging # openshift_logging_kibana_hostname=kibana.apps.testgucore.openshift.opentlc.com openshift_logging_es_cluster_size=1 openshift_logging_es_nodeselector={"env":"infra"} openshift_logging_kibana_nodeselector={"env":"infra"} openshift_logging_curator_nodeselector={"env":"infra"} Some are deprecated but NFS PVC for logging is created.
We shouldn't need to be setting legacy variables in 3.7, Eric can you take a look at the vars described in comment 0 and comment 1 to see what's missing?
Looks like we're doing a comparison with the legacy variable name when it comes to checking if someone is using 'nfs'. Not sure how that was missed before... quick fix that i'll add onto another fix in the same space
https://github.com/openshift/openshift-ansible/pull/6895
Verified and pass using openshift-ansible-3.9.1-1.git.0.9862628.el7.noarch. Note that openshift_logging_storage_x variables can only be used for deploy logging alone side with cluster deploy. openshift_logging_storage_kind=nfs openshift_logging_storage_access_modes=['ReadWriteOnce'] openshift_logging_storage_nfs_directory=/srv/nfs openshift_logging_storage_nfs_options='*(rw,root_squash)' openshift_logging_storage_volume_name=logging-es openshift_logging_storage_volume_size=10Gi openshift_logging_storage_labels={'storage': 'logging'}
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0489