Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-1467

Expand Collector Configuration Capabilities


    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Undefined Undefined
    • Logging 5.4.0
    • None
    • Log Collection
    • None
    • Expand Fluentd Configuration Capabilities
    • False
    • False
    • NEW
    • To Do
    • OBSDA-53 - Add support for using Kerberos authentication for Kafka inside the Log Forwarding API
    • OBSDA-53Add support for using Kerberos authentication for Kafka inside the Log Forwarding API
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined


      • Provide user's with expanded control of configuring the fluentd collector
      • Minimize the number of additional fields added to CLF API


      • Provide validation of combinations of configurations


      Customer's have increasingly requested the capability to modify configurations in order to address their specific environment requirements. The solution we recommend now is to set CL to "unmanaged" and modify the configuration directly. This places customer deployments in an unsupported state and subject to clobbering their changes when CL is returned to a "managed" state(i.e. for upgrades). The current recommendation introduces an additional customer burden by adding steps to their "day 2" administration.


      We could continue to recommend utilizing the "Unmanaged" solution or customer's can deploy their own log collection stack.

      Acceptance Criteria

      • Administrators can add specific configuration options per spec'd output
      • Spec'd output configuration for recognized settings are applied to the generated collector output configuration (e.g. fluent forward "deny_keepalive") where "recognized" are documented configuration keys
      • "Unrecognized" settings are ignored

      Risk and Assumptions


      There is an inherent risk administrators may configure:

      • output settings that do not all work together
      • It may not possible for us to apply validation to keep user's from bad configurations
      • We can not realistically do e2e testing of all combinations of the various configuration capabilities


      We assume:

      • Administrators understand the risks they are undertaking by doing more advanced configurations

      Documentation Considerations

      • Spec'd config as added as-is to the generated config
      • Admins undertake the risks associated with mismatched

      Open Questions

      • Can we provide "status" for failed configuration

      Additional Notes

            rhn-engineering-aconway Alan Conway
            jcantril@redhat.com Jeffrey Cantrill
            Qiaoling Tang Qiaoling Tang
            0 Vote for this issue
            2 Start watching this issue