Cause:
Missing reconciliation of a collector dead end condition when none of log store or logforwarding status is provided by the user in the ClusterLogging and/or LogFowarding custom resources.
Consequence:
Fluentd is crashlooping because no configuraiton is provided.
Fix:
Provide am empty configuration for fluentd to enable pods startup. In addition report DeadEnd condition in Logfowarding custom restource status to inform users of manual intervention demand.
Result:
Fluentd starts as expected given a ClusterLogging custom resource with only a collection stanza. In addition if a LogFowarding custom resource provided with zero valid outputs a condition named DeadEnd will be reported in the status field.
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:2871
Verified this on 4.4.0-0.nightly-2020-07-04-120349, fluentd pods starts just with the below configuration as expected. apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: collection: logs: fluentd: {} type: fluentd $ oc get pods -n openshift-logging NAME READY STATUS RESTARTS AGE cluster-logging-operator-7f9c8d494b-bmw8m 1/1 Running 0 3m fluentd-2pgt7 1/1 Running 0 2m9s fluentd-h78b8 1/1 Running 0 2m8s fluentd-m4fzh 1/1 Running 0 2m8s fluentd-mt7ch 1/1 Running 0 2m8s fluentd-n2xh2 1/1 Running 0 2m9s fluentd-wsn2z 1/1 Running 0 2m9s Moving this bug to verified state.