[enhancement] Enable tenant ClusterLogForwarders
ctrought opened this issue · 1 comments
Curious what is the appetite from other users and/or maintainers of CLO to implement the ClusterLogForwarder config at a per namespace level? The idea would be to either
A) optionally let CLO watch resources in all namespaces (specifically ClusterLogForwarder resources), so that multiple CLF configurations could be defined across other namespaces to allow each namespace user to configure the forwarding configuration for their specific namespace. The CLF for non openshift-logging namespaces would have the input namespace implied as its own, ignore app/audit/infra definitions in a pipeline, and the namespace admin(s) would be able to create their own inputs, outputs & pipelines.
B) create a new API "LogForwarder" that is the same as ClusterLogForwarder, but omits certain fields that wouldn't be required like inputs[].applications, and each input would more or less just container an option pod label selector. everything else would mostly mirror CLF as that API evolves so it might just add unnecessary overhead if the existing CLF could suffice with some additional rules implemented for user namespace configurations.
In either case they could be processed and merged into a final rendered forwarding config? Any big issues with either approach?
This is being addressed as part of enabling multi-CLF:
- JIRA: https://issues.redhat.com/browse/LOG-1343
- Enhancement Proposal: https://github.com/openshift/enhancements/blob/master/enhancements/cluster-logging/multi-cluster-log-forwarder.md
- Documentation in this repo: https://github.com/openshift/cluster-logging-operator/blob/master/docs/administration/clusterlogforwarder.adoc#cluster-log-forwarding
This is fundamentally development complete. We are working through bugs and intend to formally release later this year.
"NamespacedLogForwarding" has been a concept in our backlog for sometime but if and when it becomes a reality is TBD