Description of problem: It's impossible to use the plugin to configure the TLS forward properly. The template used to create the forward configuration file has commented the line where the private key for the client is specified. See current file for 4.4: https://github.com/openshift/cluster-logging-operator/blob/b04d1bc8c674111fe93e868e5dd84ac32a021974/pkg/generators/forwarding/fluentd/templates.go#L496 Version-Release number of selected component (if applicable): OpenShift 4 Additional info: As a workaround, the instance can be set to unmanaged, edit the line in the configmap to comment it out and the change will remain. But if the code has even the parameter substitution, why is the line commented?
Jeff, the documentation mentions the private key as part of the secret, the template includes the field (while it could just omit it), the code sets the variable in the proper line and there's a part of the test which sets the private key. It looks as easy as that somebody just forgot to remove the #. Actually that's the solution to make it work, remove the #. There's nothing new to implement, just removing the # in the template which somebody forgot to remove. Is that an RFE? Please re-consider it.
Sergio, can you point me to the documentation please.
@Christian: https://docs.openshift.com/container-platform/4.3/logging/config/cluster-logging-log-forwarding.html#cluster-logging-log-forwarding-about_cluster-logging-log-forwarding At the beginning of the page: "An output supports TLS communication using a secret. Secrets must have keys of: tls.crt, tls.key, and ca-bundler.crt which point to the respective certificates for which they represent. Secrets must have the key shared_key for use when using forward in a secure manner." Then, right after that part there's an example which shows how to configure a secured external log aggregator using the forward plug-in. As tried to explain: the feature is already in place, actually if you check the code you will see that the key is filled in the template. We just need to remove the # to send the private key no matter if the other side will validate it or not. That's why I think this is not an RFE but a bug. Someone forgot to remove the # for any reason.
Reopening since this still seems to affect 4.5 (and master branch)
Moving to UpcomingSprint as unlikely to be addressed by EOD
Moving to 4.7 to satisfy CF requirements for 4.6
Marking UpcomingSprint as will not be merged or addressed by EOD
Setting UpcomingSprint as unable to resolve before EOD
Will be fixed as part of https://bugzilla.redhat.com/show_bug.cgi?id=1888943
Fixed by PR https://github.com/openshift/cluster-logging-operator/pull/823 awaiting merge.
Closing NEXT RELEASE as this will be fixed as indicated in #c16 in GA