use mux_client_mode instead of use_mux_client

Instead of the `openshift_logging_use_mux_client` boolean parameter,
use `openshift_logging_mux_client_mode` which will allow us to support
different mux client use cases:
The value `maximal` will cause Fluentd to perform as much of the
processing as possible at the local node.  This currently means all of
the processing *except* for the Kubernetes metadata processing, which will
be done by mux.  This is the currently recommended mode to use due to
current scaling issues.
The value `minimal` means that Fluentd will do *no* processing at all,
and send the raw logs to mux for processing.  This is currently not
recommended to use due to current scaling issues.  Ansible will warn
you if you try to use this mode.

`MUX_ALLOW_EXTERNAL` is no longer needed in the mux dc.  mux now always
operates to process external logs.  The ansible setting
`openshift_logging_mux_allow_external` is still required in order to
set up the mux service to accept connections from outside of the
cluster.

2 files changed, 11 insertions, 6 deletions

diff --git a/roles/openshift_logging/README.md b/roles/openshift_logging/README.md
index 97650e2ce..84ead3548 100644
--- a/roles/openshift_logging/README.md
+++ b/roles/openshift_logging/README.md
@@ -135,16 +135,23 @@ Elasticsearch OPS too, if using an OPS cluster:
   secure_forward forwarder for the node agent Fluentd daemonsets running in the
   cluster.  This can be used to reduce the number of connections to the
   OpenShift API server, by using `mux` and configuring each node Fluentd to
-  send raw logs to mux and turn off the k8s metadata plugin.
+  send raw logs to mux and turn off the k8s metadata plugin.  This requires the
+  use of `openshift_logging_mux_client_mode` (see below).
 - `openshift_logging_mux_allow_external`: Default `False`.  If this is `True`,
   the `mux` service will be deployed, and it will be configured to allow
   Fluentd clients running outside of the cluster to send logs using
   secure_forward.  This allows OpenShift logging to be used as a central
   logging service for clients other than OpenShift, or other OpenShift
   clusters.
-- `openshift_logging_use_mux_client`: Default `False`.  If this is `True`, the
-  node agent Fluentd services will be configured to send logs to the mux
-  service rather than directly to Elasticsearch.
+- `openshift_logging_mux_client_mode`: Values - `minimal`, `maximal`.
+  Default is unset.  Setting this value will cause the Fluentd node agent to
+  send logs to mux rather than directly to Elasticsearch.  The value
+  `maximal` means that Fluentd will do as much processing as possible at the
+  node before sending the records to mux.  This is the current recommended
+  way to use mux due to current scaling issues.
+  The value `minimal` means that Fluentd will do *no* processing at all, and
+  send the raw logs to mux for processing.  We do not currently recommend using
+  this mode, and ansible will warn you about this.
 - `openshift_logging_mux_hostname`: Default is "mux." +
   `openshift_master_default_subdomain`.  This is the hostname *external*_
   clients will use to connect to mux, and will be used in the TLS server cert
diff --git a/roles/openshift_logging/defaults/main.yml b/roles/openshift_logging/defaults/main.yml
index 1c243f934..8b0f4cb62 100644
--- a/roles/openshift_logging/defaults/main.yml
+++ b/roles/openshift_logging/defaults/main.yml
@@ -157,8 +157,6 @@ openshift_logging_storage_access_modes: "{{ openshift_hosted_logging_storage_acc
 # mux - secure_forward listener service
 openshift_logging_mux_allow_external: False
 openshift_logging_use_mux: "{{ openshift_logging_mux_allow_external | default(False) }}"
-# this tells the fluentd node agent to use mux instead of sending directly to Elasticsearch
-openshift_logging_use_mux_client: False
 openshift_logging_mux_hostname: "{{ 'mux.' ~ (openshift_master_default_subdomain | default('router.default.svc.cluster.local', true)) }}"
 openshift_logging_mux_port: 24284
 openshift_logging_mux_cpu_limit: 500m