Goals

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

Non-Goals

• Provide validation of combinations of configurations

Motivation

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.

Alternatives

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

Risks

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

Assumptions

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