Bug 1490647
| Summary: | 3.6.2: logging-fluentd deployed with openshift_logging_use_mux=false fails to start due to missing mux secrets | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Mike Fiedler <mifiedle> |
| Component: | Logging | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED ERRATA | QA Contact: | Anping Li <anli> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.1 | CC: | anli, aos-bugs, jcantril, rmeggins |
| Target Milestone: | --- | ||
| Target Release: | 3.7.z | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
When deploying logging-fluentd with secure-forward to send the collected logs to logging-mux, it requires openshift_logging_mux_client_mode=maximal with openshift_logging_use_mux=True in the ansible inventory if the fluentd container and the mux container are on the same node.
If openshift_logging_mux_client_mode=maximal is set without openshift_logging_use_mux=True, the mux secret directory "/etc/fluent/muxkeys" is mounted in the fluentd container although the secret directory does not exist. It makes fluentd hang when it tries to access the mux secrets at the startup time.
This patch checks the value of openshift_logging_mux_client_mode and openshift_logging_use_mux in the ansible playbook and if the former is true while the latter is false, then it does not mount the mux secret directory in the fluentd container.
Also, the fluentd start script finds the mux secret directory does not exist, it disables openshift_logging_mux_client_mode even if it is enabled.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-11-28 22:10:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mike Fiedler
2017-09-12 00:13:44 UTC
You have specified openshift_logging_mux_client_mode=maximal and openshift_logging_use_mux=false which one should take precedence? Ok, I see - the assumption is (and probably the more intuitive assumption) is that use_mux=false controls _all other mux parameters_. +1 to comment 2. Apologies for the mixed-up inventory. Do we need to modify ansible to resolve or is this user error? @jcantrill yes - if openshift_logging_use_mux=False, then all other mux related parameters should be set to False (if boolean) or removed (e.g. openshift_logging_mux_client_mode should be undefined) Pull Requests https://github.com/openshift/openshift-ansible/pull/5693 https://github.com/openshift/origin-aggregated-logging/pull/705 Commits pushed to master at https://github.com/openshift/origin-aggregated-logging https://github.com/openshift/origin-aggregated-logging/commit/9954e962e62c8ef512ce6c7a0af7974f2afdbaf9 Bug 1490647 - logging-fluentd deployed with openshift_logging_use_mux=false fails to start due to missing If openshift_logging_use_mux=False and openshift_logging_mux_allow_external=False, then all other mux related parameters should be set to False (if boolean) or removed (e.g. openshift_logging_mux_client_mode should be undefined). To determine if mux is configured in run.sh, check whether the directory /etc/fluent/muxkeys exits or not. If it does not exist, MUX_CLIENT_MODE is unset. https://github.com/openshift/origin-aggregated-logging/commit/c50b8551f75b69fa4b61885d234b64c97647c2cd Merge pull request #705 from nhosoi/bz1490647 Automatic merge from submit-queue. Bug 1490647 - logging-fluentd deployed with openshift_logging_use_mux=false fails to start due to missing If openshift_logging_use_mux=False and openshift_logging_mux_allow_external=False, then all other mux related parameters should be set to False (if boolean) or removed (e.g. openshift_logging_mux_client_mode should be undefined). To determine if mux is configured in run.sh, check whether the directory /etc/fluent/muxkeys exits or not. If it does not exist, MUX_CLIENT_MODE is unset. koji_builds: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=605535 repositories: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-fluentd:rhaos-3.7-rhel-7-docker-candidate-91975-20171009193313 brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-fluentd:latest brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-fluentd:v3.7.0 brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-fluentd:v3.7.0-0.146.0.1 brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/logging-fluentd:v3.7 Commits pushed to master at https://github.com/openshift/openshift-ansible https://github.com/openshift/openshift-ansible/commit/554a9281265e0234af6a1de4142c67f5f8061de1 Bug 1490647 - logging-fluentd deployed with openshift_logging_use_mux=false fails to start due to missing If openshift_logging_use_mux=False and openshift_logging_mux_allow_external=False, then all other mux related parameters should be set to False (if boolean) or removed (e.g. openshift_logging_mux_client_mode should be undefined). https://github.com/openshift/openshift-ansible/commit/af04da3ae11cfe5cc80de214a4ec665f1d1676b1 Merge pull request #5693 from nhosoi/bz1490647 Automatic merge from submit-queue. Bug 1490647 - logging-fluentd deployed with openshift_logging_use_mux=false fails to start due to missing If openshift_logging_use_mux=False and openshift_logging_mux_allow_external=False, then all other mux related parameters should be set to False (if boolean) or removed (e.g. openshift_logging_mux_client_mode should be undefined). I deployed the logging with similar inventory using openshift-ansible:v3.7.0-0.148.0 successfully. The bug should be fixed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:3188 |