Description of problem: The customer desires the ability to deploy fluentd standalone using the CLO. However, this requires that additional pieces be defined even if they're not necessary. Version-Release number of selected component (if applicable): Openshift 4.4 How reproducible: Always Steps to Reproduce: 1. Install CLO 2. Use the following spec for the ClusterLogging object ``` spec: collection: logs: fluentd: {} type: fluentd ``` Actual results: No fluentd pods are started Expected results: fluentd pods would be started Additional info: I was able to get this to work using the following spec ``` spec: collection: logs: fluentd: resources: limits: memory: 736Mi requests: cpu: 100m memory: 736Mi type: fluentd logStore: elasticsearch: nodeCount: 0 type: elasticsearch managementState: Managed visualization: kibana: replicas: 0 type: kibana ```
Bumping priority to urgent as this is desired for logforwarding
@jcantrill & @ewolinetz The fix for 4.6 and 4.5 is the attached PR. Basically it was working until we introduced the fluentd init container. For later we need to check also that a logstore of type elasticsearch is present in the ClusterLogging CR spec. However, 4.4 and 4.3 seem to be a different story, because the underlying fix for the crash looping fluentd pods is [1], where we transitioned CLBO to a Condition CollectorDeadEnd in ClusterLogging's status field. Do you think we should backport this to 4.4 and 4.3 although it is a LF TP minor improvement? @Chad Scribner Any prospect to update to 4.5? Besides, can you elaborate how you are going to configure the underlying fluentd? Do you intend to use Unmanaged mode? [1] https://github.com/openshift/cluster-logging-operator/pull/422
(In reply to Periklis Tsirakidis from comment #5) > @jcantrill & @ewolinetz > > The fix for 4.6 and 4.5 is the attached PR. Basically it was working until > we introduced the fluentd init container. For later we need to check also > that a logstore of type elasticsearch is present in the ClusterLogging CR > spec. However, 4.4 and 4.3 seem to be a different story, because the > underlying fix for the crash looping fluentd pods is [1], where we > transitioned CLBO to a Condition CollectorDeadEnd in ClusterLogging's status > field. Do you think we should backport this to 4.4 and 4.3 although it is a > LF TP minor improvement? > > @Chad Scribner > Any prospect to update to 4.5? Besides, can you elaborate how you are going > to configure the underlying fluentd? Do you intend to use Unmanaged mode? > > > [1] https://github.com/openshift/cluster-logging-operator/pull/422 It'll be managed mode using secure forward to an external (customer managed) fluentd instance. The customer only needs a fix for this in OCP 4.5 and later.
Alright if we want it only in 4.5 and later, we can backport my fix. 4.6 needs to wait until we merge our LF GA.
@jcantrill This is sufficiently working on 4.6 after merging LF GA. I will send it to QA to enable backporting.
Verified on master branch
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 (OpenShift Container Platform 4.6 GA Images), 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:4196