Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1770654

Summary: The CLO does not manage fluentd when forward type is elasticsearch in the logforwarding instance.
Product: OpenShift Container Platform Reporter: Qiaoling Tang <qitang>
Component: LoggingAssignee: IgorKarpukhin <ikarpukh>
Status: CLOSED ERRATA QA Contact: Anping Li <anli>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.3.0CC: aos-bugs, ewolinet, jcantril, rmeggins
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-23 11:12:05 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 Qiaoling Tang 2019-11-11 03:44:27 UTC
Description of problem:
Deploying logging operators via OLM, then create clusterlogging instance with logforwarding enabled, and create logforwarding instance, wait until all pods become running, delete the fluentd daemonset, wait for a few minutes, the fluentd daemonset is not recreated.

Version-Release number of selected component (if applicable):
ose-cluster-logging-operator-v4.3.0-201911081316

How reproducible:
Always

Steps to Reproduce:
1. deploy logging, create clusterlogging instance with:
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  annotations:
    clusterlogging.openshift.io/logforwardingtechpreview: enabled
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      redundancyPolicy: "SingleRedundancy"
      resources:
        requests:
          memory: "4Gi"
      storage:
        storageClassName: "gp2"
        size: "20Gi"
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
  curation:
    type: "curator"
    curator:
      schedule: "*/10 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

2. create logforwarding instance
apiVersion: logging.openshift.io/v1alpha1
kind: LogForwarding
metadata:
  annotations:
    clusterlogging.openshift.io/logforwardingtechpreview: enabled
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - name: clo-default-output-es
      type: elasticsearch
      endpoint: 'elasticsearch.openshift-logging.svc:9200'
      secret:
        name: elasticsearch
  pipelines:
    - name: clo-default-app-pipeline
      inputType: logs.app
      outputRefs:
        - clo-default-output-es
    - name: clo-default-infra-pipeline
      inputType: logs.infra
      outputRefs:
        - clo-default-output-es
3. wait for about 5 minutes, delete the daemonset fluentd
4. check the daemonset in the openshift-logging namespace, the ds/fluentd is not recreated

Actual results:
The ds/fluentd could not be recreated after deleting it when logforwarding is enabled.

Expected results:
The CLO could manage the fluentd when logforwarding is enabled.

Additional info:

Comment 1 IgorKarpukhin 2019-11-14 09:55:59 UTC
The latest version of CLO (master) doesn't have such a problem. Tested on a 4.2 Openshift with the latest CLO:

[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentd   6         6         6       6            6           kubernetes.io/os=linux   2m45s
[ikarpukh@ikarpukh ~]$ oc delete daemonset fluentd -n openshift-logging
daemonset.extensions "fluentd" deleted
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
No resources found.
[ikarpukh@ikarpukh ~]$ oc get daemonsets -n openshift-logging
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentd   6         6         0       6            0           kubernetes.io/os=linux   2s

Comment 2 IgorKarpukhin 2019-11-14 13:37:19 UTC
@Anping Li, @Qiaoling Tang could you please test it with the latest version of CLO?

Comment 3 Qiaoling Tang 2019-11-15 01:16:04 UTC
No issue with ose-cluster-logging-operator-v4.3.0-201911141101

Comment 4 Qiaoling Tang 2019-11-15 03:31:09 UTC
This issue is reproduced when forward type is elasticsearch.

Comment 5 IgorKarpukhin 2019-11-15 11:41:16 UTC
@Qiaoling Tang could you please provide logs for CLO from your test cluster after removing the fluentd daemonset?

------
oc logs -f --tail=10 $(oc get pods -n openshift-logging | grep logging-operator | awk '{print $1}') -n openshift-logging
------

Comment 6 Qiaoling Tang 2019-11-18 03:38:44 UTC
I tested with ose-cluster-logging-operator-v4.3.0-201911161914, no issue now. I'll close this BZ.

Comment 8 errata-xmlrpc 2020-01-23 11:12:05 UTC
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-2020:0062